Mac OS 9 Lives! (Classic Mac OS Forum)

Classic Mac Hardware (Troubleshooting, Upgrading, & Modifying) => Mac OS 9 Booting on Previously Unsupported Hardware => Topic started by: MacTron on October 30, 2014, 10:02:34 AM

Title: Mac Os 9 booting on: xServe G4 (Detailed Posts)
Post by: MacTron on October 30, 2014, 10:02:34 AM
There is two models of DDR xServe G4:

A) A 133 Mhz System bus and ATA 100 Hard disk Interfaces and FW400.

B) A 166 Mhz System bus and ATA 133 Hard disk Interfaces and FW800.

In the A model the ATA 100 may help, but we are pushed to try the bus overclocking using the MDD procedure, never tested in the Xserve...

Getting rid the Open Firmware barrier to a  MacRISC2 kernel (Mac Os 9) it isn't easy, but it was done before. The real challenge comes now:

Comparing the PowerMac G4 MDD Architecture Block Diagram:

(http://www001.upp.so-net.ne.jp/medicalmac/im2/pbg4mdd.b.gif)

With the xServe G4 (133Mhz Bus) Architecture Block Diagram:

(http://www001.upp.so-net.ne.jp/medicalmac/im2/xserveblock.gif)

It's easy to see that the secondary PCI bus is really different from the MDD one. There is two PCI bridge interfaces ic (integrated circuit) and two ATA 100 ic. Probably Mac Os ROM 10.2.1 don't understand this part of the motherboard, so if don't bring it to a crash, it is better to ignore it by now.

So our possibilities must be limited to Uni-North 2 direct devices: Firewire, Ethernet, AGP etc...
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on October 30, 2014, 01:25:23 PM
This is the Simplified Block Diagram of the xServe G4 FW800 (slot load). The FW400 model is very similar but without FW800 ports :)

(http://macos9lives.com/smforum/index.php?action=dlattach;topic=1964.0;attach=1420)

The light red zone is the more problematic one: the ATA ic and the PCI bridge. If Mac Os ROM 10.2.1 can't "drive" the first PCI bridge we lost the CD drive, USB and serial port etc. If Mac Os ROM 10.2.1 can't "drive" the second PCI bridge we lost The PCI slots! and the possibility of booting the machine with a Hard Disk connected to a PCI card! (SATA, FW, SCSI or USB)

(http://macos9lives.com/smforum/index.php?action=dlattach;topic=1964.0;attach=1424)

In this picture, the blue color zones are the problematic ones, and the red are the VERY problematic ones...
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on October 30, 2014, 02:07:04 PM
So the procedure is:

- To use a basic installation of Mac Os 9.2 (ROM 10.2.1) in to a device connected to a port that this OS can "drive", We have to try FW, Ethernet, USB, PCI cards, etc...

- To trick the Open Firmware or Mac Os ROM to avoid the MacRisc3 closed door. For this we have to Hex Edit the ROM, change the NVRAM settings or in the last chance Reflash the firmware ¿?

Probably we have to remove some xServe components to try to avoid a system crash...

The successful possibilities are very low. In the best case we can achieve that the xServe boot in to Mac Os 9, but most of the components couldn't work...

In the worst case the xServe never go further than a grey screen, but at least, we try to learn something of the "inner soul" of this lovely machines...

MacTron
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: IIO on October 30, 2014, 03:08:18 PM
And try to trick the Open Firmware for Mac Os ROM to avoid the MacRisc3 closed door. For this we have to Hex Edit the ROM, change the NVRAM settings or in the last chance Reflash the firmware ¿?

in theory, you´d just remove the "risc3" entry (from somewhere at the beginning) of the rom. but maybe that also has disadvantes. :)
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on October 31, 2014, 11:41:34 AM
Here we have an intro to Macintosh boot:

http://macos9lives.com/smforum/index.php?topic=1965.msg9990#msg9990

The New World ROM also sets the "compatible" property of the root node to "MacRISC2" (machines that can boot classic Mac OS using "Mac OS ROM") or "MacRISC3" (machines that can only boot OS X or another Unix-like system).

So after the machine "basic" boot procedure (Open Firmware), we have to to enable a Mac Os 9 ROM to boot on a MacRisc3 Mac (the xServe, or any other Os X only G4). Here we have a guide on how to solve this:

http://macos9lives.com/smforum/index.php?topic=1967.msg9998#msg9998
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on November 01, 2014, 04:34:15 AM
In the xServe FW400 we have to change this properties in Open Firmware:
MacRISC3 and RackMac1,1

MacRISC3 should be changed by MacRISC2.

RackMac1,1 can be left as is, at first try. Later can be changed  it to  PowerMac3,6 (PM G4 MDD) u others models ¿?
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: DieHard on November 03, 2014, 08:48:18 AM
Mactron... I am so interested in the results of this thread. 

Circa 2003/2004 we had 2 extra Apple Xserve G4/1.33 (Slot Load) models in our warehouse and I was going to experiment converting them into OS 9 DAW Units.

Unfortunately, we had standardized on both the 933 QS and single 1.25 MDD, so when my partner and service manager heard the fans, which get pretty loud, it was a company decision to abandon research in getting 9.2.2 and DAW apps on it; which really pissed me off.  I left the company (in New York) and moved to CA at the end of 2004 for other reasons and never got a chance to experiment with another Xserve.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: supernova777 on November 03, 2014, 10:33:24 AM
interesting to see the inclusion of the "promise pdc20270"
this is the same chipset off the original "fasttrack" ide raid pci cards
which i was writing about suspecting them as the origin of the
"mac bootable" seritek firmware after reading the hex code inside the firmware file
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on November 03, 2014, 01:43:10 PM
interesting to see the inclusion of the "promise pdc20270"
this is the same chipset off the original "fasttrack" ide raid pci cards
which i was writing about suspecting them as the origin of the
"mac bootable" seritek firmware after reading the hex code inside the firmware file

Yes, it is Interesting...

Mactron... I am so interested in the results of this thread. 

Yes, me too... LOL

Those are just "preliminary studies" ...
An "active member" of the forum  kindly offered me a machine to test ...

So, we will see ...

I'm waiting to do the real test ...

Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: IIO on November 03, 2014, 07:28:43 PM
when i remember right, the guy where you took these pictures of the ROM hacking from never managed to come beyond the first half of the boot screen os OS9.

i would probably be much more fun to take a DDR-MDD and put it into a proper 6x19" case, right beside the PIC expansion, midi and audio IOs, ethernet switches and all this other 19" stuff.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: supernova777 on November 03, 2014, 11:05:38 PM
IIO do u even bother to re-read what u write before u press enter??
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: blemk on November 09, 2014, 04:47:21 PM
Just getting started here (this forum), but excited to see a thread started about the G4 Xserve as well. I was so close to nabbing one (dual 1.33 Ghz/167mhz) on ebay about a month ago to go do this same line of experimenting (OS 9 on it).
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: DieHard on December 08, 2014, 05:06:27 PM
 :'( :'( :'(

Unfortunately, Initial Tests are a Failure

Preliminary Tests on Xserve G4 1.33Ghz (Single CPU)
SN# QP334024N9A


Boot Attempt 1: FireWire

Boot attempt from External FireWire 400 Hard Drive using FW800 to FW400 Cable with Modified Mac OS 9.2.2 System Folder
(ROM 10.2.1 Mofied by iMic)

Here is the picture after Holding Option Key to scan boot devices...

(http://www.macos9lives.com/_img/XServe/FWBoot1.jpg)

After Selecting the FW Drive to Boot... nothing happens and this is displayed

(http://www.macos9lives.com/_img/XServe/FWBoot2.jpg)

Boot Attempt 2: USB Flash

Boot attempt from USB Flash with Modified Mac OS 9.2.2 System Folder
(ROM 10.2.1 Mofied by iMic)

Here is the picture after Holding Option Key to scan boot devices...

(http://www.macos9lives.com/_img/XServe/USBBoot.jpg)

USB Flash is NOT recognized as valid Boot device...


Boot Attempt 3: CD-ROM

Boot attempt Bootable CD with Modified Mac OS 9.2.2 System Folder
(ROM 10.2.1 Mofied by iMic)

Here is the picture after Holding "C" Key to boot to CD-ROM...

(http://www.macos9lives.com/_img/XServe/CDBoot1.jpg)

After Selecting the CD Drive to Boot... nothing happens and this is displayed

(http://www.macos9lives.com/_img/XServe/CDBoot2.jpg)




Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: supernova777 on December 08, 2014, 05:18:53 PM
my 2 cents...
if it was mine..
i would keep an xserve a server.. and keep a g4 a g4..
its compact it was designed to be a server.. let it serve your mac os 9 files with osx
afp is your friend!!!! afp + gigabit ethernet <3 a match made in heaven

BUT!! first swap its cpu out to an MDD ;) steal its brain!

Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: DieHard on December 08, 2014, 05:26:30 PM
Way too loud for me :(

Yes... CPU will be going into MDD and Xserve will be parted out on eBay and scrapped after iMic and Mactron are satisfied
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: Jakl on December 09, 2014, 01:01:57 AM
Diehard was the CD-ROM an externally connected device? If so then a fresh install on the internal HD of the X-serve via FW400/800 has yet to be tested yet then?
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: Knezzen on December 09, 2014, 03:48:16 AM
Diehard was the CD-ROM an externally connected device? If so then a fresh install on the internal HD of the X-serve via FW400/800 has yet to be tested yet then?

Shouldn't matter at all. Looks like a dead end getting OS9 running on these machines.
What a pity :(
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on December 09, 2014, 08:03:37 AM
Looks like a dead end getting OS9 running on these machines.

This is what you can read everywhere, but not here, by now :)

Mac Os 9 booting on a xServe is a real challenge. Not a walk on park. LOL

Yes... CPU will be going into MDD and Xserve will be parted out on eBay and scrapped after iMic and Mactron are satisfied

Thank you. Now we know a bit more about this. We know that this can't be done in the "easy way". LOL

Ok. Now seriously:
What DieHard test show us is the worst scenario. Once the Mac Os ROM has to "take the control" it disappears. Can't find even to himself: the UniNorth of the xServe isn't supported by Mac OS ROM, so it can't acces to the devices directly driven by it, like Firewire.
Or may be, only the firewire chip isn't supported...

The more weird thing is the USB booting test.
To DieHard: are you sure the USB device is in good shape ie: can boot any other G4?
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS9Lives.com on December 09, 2014, 08:34:04 AM
Quote
Diehard was the CD-ROM an externally connected device? If so then a fresh install on the internal HD of the X-serve via FW400/800 has yet to be tested yet then?

No, I would have mentioned that... It was the Internal Slot-Load Optical drive, so at least we know it recognizes that as bootable with modified ROM
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on December 09, 2014, 08:38:27 AM
Suggestions for future test:
-To try to boot from a device connected to a PCI card, like SATA drive connected to a SATA PCI card.
-To remove some Xserve components that may disable the Mac Os 9 boot, like the Hard Drive bay board ...

We have to identify the UniNorth chip to compare it to the MDD one. May be we can trick the Mac Os 9 drivers to support it, it in the way iMic do it with Sound Blaster drivers ...
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: DieHard on December 09, 2014, 08:54:02 AM
There currently is no Hard drive in the Xserve, the unit came without trays, I was just trying to boot.  If you have some OF "turn off Hardware" commands, then I can try that before boot
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: jt on December 09, 2014, 08:55:16 AM
 :( Dang, 9ing got me started over here and Xserve has been on the list forever.

I'm not up to speed with developments here, so please bear with me: since Native9 seems to be out of the question for now, has a back door approach to get faux9 running in 10.4.11 on an Xserve been achieved?

Quixotic quests keep this old noggin' in the game! :D

First post here: glad to find a new playground, my much neglected sound stuff is all NuBus Architecture, so catching up on that and maybe PCI Architecture toys will be a treat.

p.s. whatever you do, don't recycle the case, less noisy guts in that sucker would probably satisfy my own Xserve yearnings. ;)

Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: max1zzz on December 09, 2014, 09:44:32 AM
Has anyone tried with the original revision of the xserve G4?
 
I have a original revision (Tray loading cd, Dual 1.0Ghz) Xserve G4, Would be interesting if it could run os9 (I'll try it myself at the weekend in no ones else has tried it)

I'm not sure if there any differences between the first and second revision of xserve G4 though, so it might might not make any difference
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: supernova777 on December 09, 2014, 10:15:07 AM
diehard dont recycle it.. swap the cpus + keep it functional as an X fileserver!!! serving 9 via AFP! even if it came without the disk trays u could use an ESATA card (like the one that protoolsLE5guy bought) (http://www.firmtek.com/seritek/seritek-2se4/) that supports port multiplier + use an external enclosure /w multiple drives (such as http://www.firmtek.com/seritek/seritek-2eEN4/)

(http://www.firmtek.com/seritek/seritek-2eEN4/SeriTek-2eEN4_b.jpg)
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on December 09, 2014, 10:19:52 AM
Has anyone tried with the original revision of the xserve G4?
 
I have a original revision (Tray loading cd, Dual 1.0Ghz) Xserve G4, Would be interesting if it could run os9 (I'll try it myself at the weekend in no ones else has tried it)

I'm not sure if there any differences between the first and second revision of xserve G4 though, so it might might not make any difference

The original revision have a 133 Mhz System bus and ATA 100 Hard disk Interfaces and FW400, this should make the mac Os 9 boot "easy" ...
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: Protools5LEGuy on May 08, 2016, 08:56:10 PM
Yeah Elliot and I are working together on this. 
I actually have this crazy idea now that we can probably get some level of booting on the mac mini and xserve g4's with some creative complicated manual open firmware adjustments.  Still probably won't boot very far, but it's entirely possible.
Booting the xServe with Mac Os 9 may be a great conquest. But while as it have very similar parts to a MDD, it have other very different components, wich can difficult the Mac Os 9 booting.
Here we have an early  draft of this project:

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

I like a challenge, even if it is unrealistic.

...  And I have a spare xServe Rev 1 lying around doing nothing.  If I can get OS 9 working on it then I'll have an excuse to actually make use of it!  I even have the substitute AGP riser available so I have more choice of video cards.

  I suppose, in the end, anything learned in success or failure on the 'less-realistic' machines will still go a long way towards achieving full function of the other machines we're much closer on.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on May 09, 2016, 10:14:43 PM
Since I seem to have inadvertently raised this thread from the dead, I have a question:

  I'm going to try to help Nanopico and Elliot with their "crazy idea".  I have two Rev. 1 xServes at my disposal, one actively running OS X 10.5 as a functional point of reference, and a second 'twin' I will put to work testing OS 9 booting.

  What I'm wondering about is which video cards are likely to be supported properly in this system under OS 9?  The base configuration of these xServes was a PCI video card in the dual-slot riser.  (In this arrangement the single-slot PCI riser would contain a gigabit ethernet card.)  The optional configuration was a substitute AGP 4x slot riser replacing the single-slot PCI riser and then using a non-ADC ATI Radeon 8500.

  Either way around is atypical of the other G4 systems of this generation.  Any ADC-based card probably won't work at all, even on the VGA port, and might even damage the host system without pin taping.  PCI cards would for the most part offer a limited performance and selection also.  I am open to adding to my collection of video cards if there is something best for this system test that I don't already have.  There is also the possibility of re-flashed PC video cards, of which I already have some.  I really have no idea what sort of fundamental compatibility issues might arise when combining any card with the firmware and hardware environment of the xServe.  I've learned from experience with other Mac machines that sometimes just getting video to display at all is sometimes impossible with certain cards in certain motherboards.

  I have a lot of video cards around but not many I would expect to work in the xServe under OS 9.  Hopefully someone on the forums can help narrow this down for me.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on May 10, 2016, 05:07:44 AM
From my view point, any card that will not damage the hardware and has the correct firmware to let Open Firmware know it is able to be a card usable at boot is fine. (so pretty much any mac compatible card that won't trash the hardware).
It may not have acceleration or anything, but I'm more focused on the rest of the hardware getting up and running. Just my view anyway.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: devils_advisor on May 10, 2016, 05:44:52 AM
i believe my xserve had a ati 7000 series in there when it came which i put in a beige g3 at some point and it worked with games and other stuff
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on May 16, 2016, 12:42:02 PM
  Finding almost no PCI video cards in my collection that should be supported by OS 9.x's bundled drivers, I tried an ATI Rage128 from a B&W G3.  For whatever reason it wouldn't initialize the display at all.  So then I swapped out the PCI riser for the AGP riser and tried a Rage128 AGP, a real Mac non-ADC card that I happened to have.  That one did work to display the boot device screen and Open Firmware, thankfully.  I also had to back down to an older keyboard because the first one I tried wouldn't initialize properly so I couldn't get into Open Firmware.  The replacement keyboard was a full-size Graphite variant (not the older mini-format one).

  Following Elliot's instructions I generated a telnet terminal output from my xServe as far as it would go with the "Unsupported G4" OS 9.2.2 ASR disc.  As many of you may find it interesting, especially to see just how much is really going on invisibly during the boot attempt, here is the output:

Last login: Mon May 16 13:57:47 on console ***Initial telnet setup and device listing commands***
Hyper-PowerBook-G4:~ administrator$ telnet 192.168.0.250
Trying 192.168.0.250...
Connected to 192.168.0.250.
Escape character is '^]'.
 ok
0 > dev /  ok
0 > Ls
ff87ceb0: /cpus
ff87d160:   /PowerPC,G4@0
ff87d558:     /l2-cache 
ff87d790:       /l2-cache
ff87e3f8:   /PowerPC,G4@1
ff87e7f0:     /l2-cache 
ff87ea28:       /l2-cache
ff87ed38: /chosen       
ff87ef50: /memory@0
ff87f1f0: /openprom
ff87f398:   /client-services
ff880680: /rom@ff800000
ff880880:   /boot-rom@fff00000
ff880ab0:   /macos
ff880bb8: /options
ff880cc0: /aliases
ff882f90: /packages
ff883070:   /deblocker
ff883a08:   /disk-label
ff8844d0:   /obp-tftp
ff88ddb0:   /telnet
ff88e6b0:   /mac-parts
ff88ff60:   /mac-files
ff892f18:   /hfs-plus-files
ff897f98:   /fat-files
ff899d90:   /iso-9660-files
ff89abf0:   /bootinfo-loader
ff89c888:   /xcoff-loader
ff89d320:   /pe-loader
ff89dd70:   /elf-loader
ff89f418:   /usb-hid-class
ff8a1fa8:   /usb-ms-class
ff8a4bf8:   /usb-audio-class
ff912770:   /sbp2-disk
ff9151c8:   /ata-disk
ff917708:   /atapi-disk
ff919898:   /bootpath-search
ff920218:   /terminal-emulator
ff920328: /firewire-disk-mode
ff935d58: /pseudo-hid
ff935e58:   /keyboard
ff936550:   /mouse
ff936ae8:   /eject-key
ff936fb8: /pseudo-sound
ff9372e8: /multiboot
ff94a960: /diagnostics
ff94aa40: /nvram@fff04000
ff94b690: /uni-n@f8000000
ff94b958:   /i2c@f8001000
ff94c470:     /lm87
ff94cff0:     /temp-monitor@192
ff94d6f0:     /cereal
ff94de20: /pci@f0000000
ff9ab958:   /ATY,Rage128Ps@10
ff94f050: /pci@f2000000
ff9502a8:   /pci-bridge@d
ff953ce0:     /mac-io@7
ff95a7a0:       /interrupt-controller@40000
ff95a9f0:       /gpio@50
ff95ac20:         /extint-gpio1@9
ff95af10:         /programmer-switch@11
ff95b1a0:         /ringDetect-gpio@8
ff95b478:         /keySwitch-gpio@c
ff95b700:         /systemMonitor-gpio@12
ff95b940:         /indicatorSwitch-gpio@15
ff95c068:         /indicatorLED-gpio@20
ff95c348:         /virtual-sound
ff95c460:       /escc-legacy@12000
ff95c6d0:         /ch-a@12004
ff95c8d0:         /ch-b@12000
ff95cad0:       /escc@13000
ff95cd58:         /ch-a@13020
ff95d7a8:         /ch-b@13000
ff95e128:       /i2s@10000
ff95e358:         /i2s-a@10000
ff95e688:           /sound
ff95e7b0:       /timer@15000
ff95e9a8:       /via-pmu@16000
ff962078:         /pmu-i2c
ff962eb8:           /9554@140
ff963958:             /drive-power@0
ff963be0:             /drive-fail@1
ff963ea8:             /drive-inuse@2
ff964130:             /drive-present@3
ff9643c0:             /drive-switch@4
ff964648:             /drive-reset@5
ff9648c8:             /drive-power@6
ff964b48:             /drive-inuse@7
ff964dc8:           /9554@142
ff965868:             /drive-power@0
ff965af0:             /drive-fail@1
ff965db8:             /drive-inuse@2
ff966040:             /drive-present@3
ff9662d0:             /drive-switch@4
ff966558:             /drive-reset@5
ff9667d8:             /drive-power@6
ff966a58:             /drive-inuse@7
ff966cd8:           /9554@144
ff967778:             /drive-power@0
ff967a00:             /drive-fail@1
ff967cc8:             /drive-inuse@2
ff967f50:             /drive-present@3
ff9681e0:             /drive-switch@4
ff968468:             /drive-reset@5
ff9686e8:             /drive-power@6
ff968968:             /drive-inuse@7
ff968be8:           /9554@146
ff969688:             /drive-power@0
ff969910:             /drive-fail@1
ff969bd8:             /drive-inuse@2
ff969e60:             /drive-present@3
ff96a0f0:             /drive-switch@4
ff96a378:             /drive-reset@5
ff96a5f8:             /drive-power@6
ff96a878:             /drive-inuse@7
ff96aaf8:           /9554M@148
ff96b7b0:         /rtc
ff96bea8:         /power-mgt
ff9cc688:           /usb-power-mgt
ff96c1b8:       /i2c@18000
ff96cc70:         /cereal
ff96d3b8:       /ata-4@1f000
ff9700f8:         /disk
ff97ca80:     /usb@8
ff9c9ed8:       /hub@1
ff9ca0e0:         /device@1
ff9ca258:           /keyboard@0
ff9ca5e8:           /eject-key@1
ff984708:     /usb@9
ff9513c0:   /pci-bridge@11
ff98c498:   /AppleKiwi@15
ff98d660:     /ata-6@0
ff9905e0:       /disk
ff990c98:     /ata-6@1
ff993c18:       /disk
ff9942d0:   /AppleKiwi@1b
ff995498:     /ata-6@0
ff998418:       /disk
ff998ad0:     /ata-6@1
ff99ba50:       /disk
ff9524d8: /pci@f4000000
ff99c3f0:   /firewire@e
ff9a65d8:   /ethernet@f
ff9ccb88:     /ethernet-phy
ff953730: /vsp@f9000000
ff953a20:   /veo@f9080000
ff953b80:   /veo@f9180000
 ok
0 > 30CCF encode-int " AAPL,debug" property  ok
0 > mac-boot AAPL,debug bit settings (-OR- bits together): ***Boot attempt initiated on this line***
       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).

MacOS: RTAS not found.
work area logical address = 0x218000, physical address = 0x218000.
IsKeyDown: no keys held down
Found parcel 'Mac OS ROM Parcel', type 'rom '.
Checking root interrupt-controller - is it Heathrow or Paddington?
MacOS NVRAM partition offset = 0x1010
created node 'AAPL,CodePrepare'
parcel 'CodePrepare Node Parcel': Added property 'AAPL,prepare_order'.
node '': decompressing property 'TimeManagerLib'.
parcel 'CodePrepare Node Parcel': Added property 'TimeManagerLib'.
node '': decompressing property 'NVRAMServicesLib'.
parcel 'CodePrepare Node Parcel': Added property 'NVRAMServicesLib'.
MacOS: Found a plug-in for NVRAM.
node '': decompressing property 'RTCServicesLib'.
parcel 'CodePrepare Node Parcel': Added property 'RTCServicesLib'.
MacOS: Found a plug-in for RTC.
created node 'AAPL,CodeRegister'
node '': decompressing property 'NativePowerMgrLib'.
parcel 'CodeRegister Node Parcel': Added property 'NativePowerMgrLib'.
node '': decompressing property 'AGPLib'.
parcel 'CodeRegister Node Parcel': Added property 'AGPLib'.
node '': decompressing property 'StartLib'.
parcel 'CodeRegister Node Parcel': Added property 'StartLib'.
Found parcel 'Property Checksum', type 'psum'.
CRC changed from 0xFFFFFFFF to 0x88B1FADE, node 'device-tree'
CRC changed from 0x88B1FADE to 0x1FB224D8, node 'cpus'
CRC changed from 0x1FB224D8 to 0x6FCB3465, node 'PowerPC,G4'
CRC changed from 0x6FCB3465 to 0x3BADCE64, node 'l2-cache'
CRC changed from 0x3BADCE64 to 0x670F091A, node 'l2-cache'
CRC changed from 0x670F091A to 0x84670FD2, node 'PowerPC,G4'
CRC changed from 0x84670FD2 to 0x63979769, node 'l2-cache'
CRC changed from 0x63979769 to 0xB249610F, node 'l2-cache'
CRC changed from 0xB249610F to 0x532A41A6, node 'chosen'
CRC changed from 0x532A41A6 to 0xB269EB4, node 'memory'
CRC changed from 0xB269EB4 to 0xB20FE6F3, node 'openprom'
CRC changed from 0xB20FE6F3 to 0xCC679C29, node 'client-services'
CRC changed from 0xCC679C29 to 0xD9853F2, node 'rom'
CRC changed from 0xD9853F2 to 0xF71DAA7A, node 'boot-rom'
node name 'macos': Matched parcel 'macos', device_type ''.
node 'macos': Added property 'MacOSROMFile-version'.
CRC changed from 0xF71DAA7A to 0x2223338, node 'macos'
CRC changed from 0x2223338 to 0x600B38D4, node 'options'
CRC changed from 0x600B38D4 to 0xE33EC90B, node 'aliases'
CRC changed from 0xE33EC90B to 0x1B431160, node 'packages'
CRC changed from 0x1B431160 to 0xA4196B0E, node 'deblocker'
CRC changed from 0xA4196B0E to 0xCB604F80, node 'disk-label'
CRC changed from 0xCB604F80 to 0xF1ECF4A0, node 'obp-tftp'
CRC changed from 0xF1ECF4A0 to 0xCCD32F48, node 'telnet'
CRC changed from 0xCCD32F48 to 0xC38194F3, node 'mac-parts'
CRC changed from 0xC38194F3 to 0xEFA3002A, node 'mac-files'
CRC changed from 0xEFA3002A to 0xA8587508, node 'hfs-plus-files'
CRC changed from 0xA8587508 to 0x86F69C68, node 'fat-files'
CRC changed from 0x86F69C68 to 0x613F92F1, node 'iso-9660-files'
CRC changed from 0x613F92F1 to 0x203E16EE, node 'bootinfo-loader'
CRC changed from 0x203E16EE to 0xD9BEA82A, node 'xcoff-loader'
CRC changed from 0xD9BEA82A to 0xC8AD4C1A, node 'pe-loader'
CRC changed from 0xC8AD4C1A to 0x5CE55023, node 'elf-loader'
CRC changed from 0x5CE55023 to 0x497CE8EB, node 'usb-hid-class'
CRC changed from 0x497CE8EB to 0xB1BC7128, node 'usb-ms-class'
CRC changed from 0xB1BC7128 to 0x6F90F820, node 'usb-audio-class'
CRC changed from 0x6F90F820 to 0x9C0035F1, node 'sbp2-disk'
CRC changed from 0x9C0035F1 to 0x74AA1DB2, node 'ata-disk'
CRC changed from 0x74AA1DB2 to 0x64D6F6A0, node 'atapi-disk'
CRC changed from 0x64D6F6A0 to 0xE3223529, node 'bootpath-search'
CRC changed from 0xE3223529 to 0xE849A900, node 'terminal-emulator'
CRC changed from 0xE849A900 to 0x61815EB7, node 'firewire-disk-mode'
CRC changed from 0x61815EB7 to 0x6A1C0632, node 'pseudo-hid'
CRC changed from 0x6A1C0632 to 0x62070CFB, node 'keyboard'
CRC changed from 0x62070CFB to 0xCED9C312, node 'mouse'
CRC changed from 0xCED9C312 to 0x7EC7DF69, node 'eject-key'
CRC changed from 0x7EC7DF69 to 0xD2327054, node 'pseudo-sound'
CRC changed from 0xD2327054 to 0x8EF5AA9E, node 'multiboot'
CRC changed from 0x8EF5AA9E to 0x71E7D24E, node 'diagnostics'
compatible 'nvram,flash': Matched parcel 'nvram,flash', device_type 'nvram'.
node 'nvram': Added property 'driver,AAPL,MacOS,PowerPC'.
node 'nvram': decompressing property 'driver,AAPL,MacOS,PowerPC'.
CRC changed from 0x71E7D24E to 0x7E855B1D, node 'nvram'
CRC changed from 0x7E855B1D to 0xBCEC993D, node 'uni-n'
compatible 'keywest-i2c': Matched parcel 'keywest-i2c', device_type 'i2c'.
---------------- Node 'i2c' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 0000002A 00000001
unit_interrupt_specifer[0] = 42
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 0, intSource 42, level 2, sense 1, polarity 0
node 'i2c': Added property 'driver,AAPL,MacOS,PowerPC'.
node 'i2c': decompressing property 'driver,AAPL,MacOS,PowerPC'.
CRC changed from 0xBCEC993D to 0x49E34A76, node 'i2c'
CRC changed from 0x49E34A76 to 0x5C3A6A0D, node 'lm87'
CRC changed from 0x5C3A6A0D to 0xCA4C0AD3, node 'temp-monitor'
CRC changed from 0xCA4C0AD3 to 0x8F8F549D, node 'cereal'
compatible 'uni-north': Matched parcel 'uni-north', device_type 'pci'.
---------------- Node 'pci' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 0000002D 00000001
unit_interrupt_specifer[0] = 45
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 1, intSource 45, level 2, sense 1, polarity 0
node 'pci': Added property 'pef,AAPL,MacOS,PowerPC,prepare'.
node 'pci': decompressing property 'pef,AAPL,MacOS,PowerPC,prepare'.
node 'pci': Added property 'code,AAPL,MacOS,name'.
CRC changed from 0x8F8F549D to 0xACF234D0, node 'pci'
device_type 'display': Matched parcel 'cofb', device_type 'display'.
---------------- Node 'ATY,Rage128Ps' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00008000 00000000 00000000 00000001
Interrupt-map-mask values: 0000F800 00000000 00000000 00000000

Comparing interrupt-map entries to this unit_interrupt_specifier:

Masked unit_int_specifier: 00008000 00000000 00000000 00000000
Interrupt-map child spec : 00008000 00000000 00000000 00000000
New unit_int_specifier   : 00000030 00000001

unit_interrupt_specifer[0] = 48
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 2, intSource 48, level 2, sense 1, polarity 0
node 'ATY,Rage128Ps': Did NOT replace property 'driver,AAPL,MacOS,PowerPC'.
node 'ATY,Rage128Ps': Property NOT added (already loaded) 'driver,AAPL,MacOS,PowerPC'.
CRC changed from 0xACF234D0 to 0x297EB04, node 'ATY,Rage128Ps'
compatible 'uni-north': Matched parcel 'uni-north', device_type 'pci'.
---------------- Node 'pci' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 0000002D 00000001
unit_interrupt_specifer[0] = 45
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 1, intSource 45, level 2, sense 1, polarity 0
node 'pci': Property NOT added (already loaded) 'pef,AAPL,MacOS,PowerPC,prepare'.
node 'pci': Added property 'code,AAPL,MacOS,name'.
CRC changed from 0x297EB04 to 0x42FA08E0, node 'pci'
CRC changed from 0x42FA08E0 to 0x73B94A33, node 'pci-bridge'
HandleSpecialNode: Mac-IO base address = 0x80000000.
CRC changed from 0x73B94A33 to 0xA847CCB2, node 'mac-io'
HandleSpecialNode: Host OpenPIC has base address = 0x80040000.
CRC changed from 0xA847CCB2 to 0x7E1F57A9, node 'interrupt-controller'
CRC changed from 0x7E1F57A9 to 0x740C8DEE, node 'gpio'
---------------- Node 'extint-gpio1' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 0000002F 00000001
unit_interrupt_specifer[0] = 47
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 3, intSource 47, level 2, sense 1, polarity 0
CRC changed from 0x740C8DEE to 0x85C5766, node 'extint-gpio1'
---------------- Node 'programmer-switch' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000037 00000000
unit_interrupt_specifer[0] = 55
(ua_size = 0, is_size = 2) setting edge[0] to 1
OpenPIC setup: vectorIndex 4, intSource 55, level 7, sense 0, polarity 0
CRC changed from 0x85C5766 to 0x7127DD8A, node 'programmer-switch'
---------------- Node 'ringDetect-gpio' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 0000002E 00000000
unit_interrupt_specifer[0] = 46
(ua_size = 0, is_size = 2) setting edge[0] to 1
OpenPIC setup: vectorIndex 5, intSource 46, level 2, sense 0, polarity 0
CRC changed from 0x7127DD8A to 0xCFC2498C, node 'ringDetect-gpio'
---------------- Node 'keySwitch-gpio' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000032 00000000
unit_interrupt_specifer[0] = 50
(ua_size = 0, is_size = 2) setting edge[0] to 1
OpenPIC setup: vectorIndex 6, intSource 50, level 2, sense 0, polarity 0
CRC changed from 0xCFC2498C to 0xD1A1CBE0, node 'keySwitch-gpio'
CRC changed from 0xD1A1CBE0 to 0x9033E46, node 'systemMonitor-gpio'
---------------- Node 'indicatorSwitch-gpio' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 0000003B 00000001
unit_interrupt_specifer[0] = 59
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 7, intSource 59, level 2, sense 1, polarity 0
CRC changed from 0x9033E46 to 0x171619DB, node 'indicatorSwitch-gpio'
CRC changed from 0x171619DB to 0x9F5E6EDB, node 'indicatorLED-gpio'
CRC changed from 0x9F5E6EDB to 0xEE085193, node 'virtual-sound'
HandleSpecialNode: SCC legacy base address = 0x80012000.
CRC changed from 0xEE085193 to 0xB434A586, node 'escc-legacy'
---------------- Node 'ch-a' has 3 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000016 00000001
unit_interrupt_specifer[0] = 22
(ua_size = 0, is_size = 2) setting edge[0] to 0
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000005 00000000
unit_interrupt_specifer[0] = 5
(ua_size = 0, is_size = 2) setting edge[1] to 1
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000006 00000000
unit_interrupt_specifer[0] = 6
(ua_size = 0, is_size = 2) setting edge[2] to 1
OpenPIC setup: vectorIndex 8, intSource 22, level 4, sense 1, polarity 0
OpenPIC setup: vectorIndex 9, intSource 5, level 4, sense 0, polarity 0
OpenPIC setup: vectorIndex 10, intSource 6, level 4, sense 0, polarity 0
CRC changed from 0xB434A586 to 0x55E3E8C1, node 'ch-a'
---------------- Node 'ch-b' has 3 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000017 00000001
unit_interrupt_specifer[0] = 23
(ua_size = 0, is_size = 2) setting edge[0] to 0
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000007 00000000
unit_interrupt_specifer[0] = 7
(ua_size = 0, is_size = 2) setting edge[1] to 1
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000008 00000000
unit_interrupt_specifer[0] = 8
(ua_size = 0, is_size = 2) setting edge[2] to 1
OpenPIC setup: vectorIndex 11, intSource 23, level 4, sense 1, polarity 0
OpenPIC setup: vectorIndex 12, intSource 7, level 4, sense 0, polarity 0
OpenPIC setup: vectorIndex 13, intSource 8, level 4, sense 0, polarity 0
CRC changed from 0x55E3E8C1 to 0x3ABA769E, node 'ch-b'
CRC changed from 0x3ABA769E to 0x3A28DE5F, node 'escc'
HandleSpecialNode: ch-a slot-name detected.
---------------- Node 'ch-a' has 3 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000016 00000001
unit_interrupt_specifer[0] = 22
(ua_size = 0, is_size = 2) setting edge[0] to 0
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000005 00000000
unit_interrupt_specifer[0] = 5
(ua_size = 0, is_size = 2) setting edge[1] to 1
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000006 00000000
unit_interrupt_specifer[0] = 6
(ua_size = 0, is_size = 2) setting edge[2] to 1
OpenPIC setup: vectorIndex 8, intSource 22, level 4, sense 1, polarity 0
OpenPIC setup: vectorIndex 9, intSource 5, level 4, sense 0, polarity 0
OpenPIC setup: vectorIndex 10, intSource 6, level 4, sense 0, polarity 0
CRC changed from 0x3A28DE5F to 0x384CACD3, node 'ch-a'
HandleSpecialNode: ch-b slot-name detected.
---------------- Node 'ch-b' has 3 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000017 00000001
unit_interrupt_specifer[0] = 23
(ua_size = 0, is_size = 2) setting edge[0] to 0
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000007 00000000
unit_interrupt_specifer[0] = 7
(ua_size = 0, is_size = 2) setting edge[1] to 1
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000008 00000000
unit_interrupt_specifer[0] = 8
(ua_size = 0, is_size = 2) setting edge[2] to 1
OpenPIC setup: vectorIndex 11, intSource 23, level 4, sense 1, polarity 0
OpenPIC setup: vectorIndex 12, intSource 7, level 4, sense 0, polarity 0
OpenPIC setup: vectorIndex 13, intSource 8, level 4, sense 0, polarity 0
CRC changed from 0x384CACD3 to 0x1E58B87C, node 'ch-b'
CRC changed from 0x1E58B87C to 0xA6F57A73, node 'i2s'
---------------- Node 'i2s-a' has 3 interrupt(s). ----------------
Requested priorities for this node:
Dumping 12 bytes @ 0x0010D138
0010D138: 00000002 00000004 00000004

Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 0000001E 00000001
unit_interrupt_specifer[0] = 30
(ua_size = 0, is_size = 2) setting edge[0] to 0
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000001 00000000
unit_interrupt_specifer[0] = 1
(ua_size = 0, is_size = 2) setting edge[1] to 1
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000002 00000000
unit_interrupt_specifer[0] = 2
(ua_size = 0, is_size = 2) setting edge[2] to 1
OpenPIC setup: vectorIndex 14, intSource 30, level 2, sense 1, polarity 0
OpenPIC setup: vectorIndex 15, intSource 1, level 4, sense 0, polarity 0
OpenPIC setup: vectorIndex 16, intSource 2, level 4, sense 0, polarity 0
CRC changed from 0xA6F57A73 to 0x76CC62CA, node 'i2s-a'
CRC changed from 0x76CC62CA to 0x25FAFBCC, node 'sound'
HandleSpecialNode: KeyLargo timer base address = 0x80015000.
---------------- Node 'timer' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000020 00000001
unit_interrupt_specifer[0] = 32
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 17, intSource 32, level 2, sense 1, polarity 0
CRC changed from 0x25FAFBCC to 0x49E591DC, node 'timer'
HandleSpecialNode: VIA base address = 0x80016000.
---------------- Node 'via-pmu' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000019 00000001
unit_interrupt_specifer[0] = 25
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 18, intSource 25, level 1, sense 1, polarity 0
CRC changed from 0x49E591DC to 0x4DD4B5C0, node 'via-pmu'
CRC changed from 0x4DD4B5C0 to 0xA7CC71B6, node 'pmu-i2c'
CRC changed from 0xA7CC71B6 to 0xD8104800, node '9554'
CRC changed from 0xD8104800 to 0x29F6D88C, node 'drive-power'
CRC changed from 0x29F6D88C to 0x908D7843, node 'drive-fail'
CRC changed from 0x908D7843 to 0x9AA7127A, node 'drive-inuse'
CRC changed from 0x9AA7127A to 0xCC796D8, node 'drive-present'
CRC changed from 0xCC796D8 to 0xC3DFECE2, node 'drive-switch'
CRC changed from 0xC3DFECE2 to 0x2DD8311E, node 'drive-reset'
CRC changed from 0x2DD8311E to 0x7ECEB5B8, node 'drive-power'
CRC changed from 0x7ECEB5B8 to 0xDF5FCB, node 'drive-inuse'
CRC changed from 0xDF5FCB to 0x5EE6E000, node '9554'
CRC changed from 0x5EE6E000 to 0xD6358975, node 'drive-power'
CRC changed from 0xD6358975 to 0x3A708DD7, node 'drive-fail'
CRC changed from 0x3A708DD7 to 0xCA422F19, node 'drive-inuse'
CRC changed from 0xCA422F19 to 0x34E66AF3, node 'drive-present'
CRC changed from 0x34E66AF3 to 0x5B862392, node 'drive-switch'
CRC changed from 0x5B862392 to 0x2C5DA7FE, node 'drive-reset'
CRC changed from 0x2C5DA7FE to 0x2B973C53, node 'drive-power'
CRC changed from 0x2B973C53 to 0x41B897D9, node 'drive-inuse'
CRC changed from 0x41B897D9 to 0x187587B8, node '9554'
CRC changed from 0x187587B8 to 0x4E9CC8A2, node 'drive-power'
CRC changed from 0x4E9CC8A2 to 0x9D96EA3D, node 'drive-fail'
CRC changed from 0x9D96EA3D to 0xC3243510, node 'drive-inuse'
CRC changed from 0xC3243510 to 0x8AB8793D, node 'drive-present'
CRC changed from 0x8AB8793D to 0xACC6B595, node 'drive-switch'
CRC changed from 0xACC6B595 to 0xFA7F63A9, node 'drive-reset'
CRC changed from 0xFA7F63A9 to 0x5A7FEE59, node 'drive-power'
CRC changed from 0x5A7FEE59 to 0xFCEDC204, node 'drive-inuse'
CRC changed from 0xFCEDC204 to 0x1B2CEC30, node '9554'
CRC changed from 0x1B2CEC30 to 0xBF7437C9, node 'drive-power'
CRC changed from 0xBF7437C9 to 0x43E81304, node 'drive-fail'
CRC changed from 0x43E81304 to 0x938864AC, node 'drive-inuse'
CRC changed from 0x938864AC to 0x80B60A5B, node 'drive-present'
CRC changed from 0x80B60A5B to 0x53361F5, node 'drive-switch'
CRC changed from 0x53361F5 to 0xD60DF6B2, node 'drive-reset'
CRC changed from 0xD60DF6B2 to 0x6F8E4BBC, node 'drive-power'
CRC changed from 0x6F8E4BBC to 0x3A696DA4, node 'drive-inuse'
CRC changed from 0x3A696DA4 to 0xF2531B, node '9554M'
parent name 'via-pmu': Matched parcel 'via-pmu', device_type 'rtc'.
node 'rtc': Added property 'driver,AAPL,MacOS,PowerPC'.
node 'rtc': decompressing property 'driver,AAPL,MacOS,PowerPC'.
CRC changed from 0xF2531B to 0xDE2B33A1, node 'rtc'
HandleSpecialNode: Core 99 Power Mgt detected.
compatible 'via-pmu-99': Matched parcel 'via-pmu-99', device_type 'power-mgt'.
node 'power-mgt': Added property 'pef,AAPL,MacOS,PowerPC,register'.
node 'power-mgt': decompressing property 'pef,AAPL,MacOS,PowerPC,register'.
node 'power-mgt': Added property 'code,AAPL,MacOS,name'.
MacOS: Found a PowerPlugin.
Added property 'PMULib' to special node 1.
node 'power-mgt': decompressing property 'PMULib'.
CRC changed from 0xDE2B33A1 to 0x1DC1DF45, node 'power-mgt'
---------------- Node 'usb-power-mgt' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 0000001D 00000001
unit_interrupt_specifer[0] = 29
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 19, intSource 29, level 2, sense 1, polarity 0
CRC changed from 0x1DC1DF45 to 0xC846CB48, node 'usb-power-mgt'
compatible 'keywest-i2c': Matched parcel 'keywest-i2c', device_type 'i2c'.
---------------- Node 'i2c' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 0000001A 00000001
unit_interrupt_specifer[0] = 26
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 20, intSource 26, level 2, sense 1, polarity 0
node 'i2c': Added property 'driver,AAPL,MacOS,PowerPC'.
node 'i2c': decompressing property 'driver,AAPL,MacOS,PowerPC'.
CRC changed from 0xC846CB48 to 0x523C247C, node 'i2c'
CRC changed from 0x523C247C to 0x3B9B5448, node 'cereal'
compatible 'keylargo-ata': Matched parcel 'keylargo-ata', device_type 'ata'.
---------------- Node 'ata-4' has 2 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000013 00000001
unit_interrupt_specifer[0] = 19
(ua_size = 0, is_size = 2) setting edge[0] to 0
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 0000000B 00000000
unit_interrupt_specifer[0] = 11
(ua_size = 0, is_size = 2) setting edge[1] to 1
OpenPIC setup: vectorIndex 21, intSource 19, level 2, sense 1, polarity 0
OpenPIC setup: vectorIndex 22, intSource 11, level 4, sense 0, polarity 0
node 'ata-4': Added property 'driver,AAPL,MacOS,PowerPC'.
node 'ata-4': decompressing property 'driver,AAPL,MacOS,PowerPC'.
CRC changed from 0x3B9B5448 to 0xE4FD3E60, node 'ata-4'
CRC changed from 0xE4FD3E60 to 0x62CBCAAF, node 'disk'
---------------- Node 'usb' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00014000 00000000 00000000 00000001
Interrupt-map-mask values: 0000F800 00000000 00000000 00000000

Comparing interrupt-map entries to this unit_interrupt_specifier:

Masked unit_int_specifier: 00004000 00000000 00000000 00000000
Interrupt-map child spec : 00004000 00000000 00000000 00000000
New unit_int_specifier   : 0000001B 00000001

unit_interrupt_specifer[0] = 27
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 23, intSource 27, level 2, sense 1, polarity 0
CRC changed from 0x62CBCAAF to 0xEC7868B3, node 'usb'
CRC disabled for node 'hub'.
CRC disabled for node 'device'.
CRC disabled for node 'keyboard'.
CRC disabled for node 'eject-key'.
---------------- Node 'usb' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00014800 00000000 00000000 00000001
Interrupt-map-mask values: 0000F800 00000000 00000000 00000000

Comparing interrupt-map entries to this unit_interrupt_specifier:

Masked unit_int_specifier: 00004800 00000000 00000000 00000000
Interrupt-map child spec : 00004000 00000000 00000000 00000000
Interrupt-map child spec : 00004800 00000000 00000000 00000000
New unit_int_specifier   : 0000001C 00000001

unit_interrupt_specifer[0] = 28
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 24, intSource 28, level 2, sense 1, polarity 0
CRC changed from 0xEC7868B3 to 0x96237160, node 'usb'
CRC changed from 0x96237160 to 0x4ACBAC61, node 'pci-bridge'
---------------- Node 'AppleKiwi' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 0000A800 00000000 00000000 00000001
Interrupt-map-mask values: 0000F800 00000000 00000000 00000000

Comparing interrupt-map entries to this unit_interrupt_specifier:

Masked unit_int_specifier: 0000A800 00000000 00000000 00000000
Interrupt-map child spec : 0000A800 00000000 00000000 00000000
New unit_int_specifier   : 0000003A 00000001

unit_interrupt_specifer[0] = 58
(ua_size = 0, is_size = 2) setting edge[0] to 0
OpenPIC setup: vectorIndex 25, intSource 58, level 2, sense 1, polarity 0
CRC changed from 0x4ACBAC61 to 0x28C93722, node 'AppleKiwi'
---------------- Node 'ata-6' has 1 interrupt(s). ----------------
Processing unit_interrupt_specifier:
Raw unit_int_specifier   : 00000000 00000000
found a cascading interrupt controller @ 0xFF98C498
cascadeStack[0] = 0 (ua_size = 1)
(ua_size = 1, is_size = 1) setting edge[0] to 0
ua_size = 3
New UIS from 'reg' prop  : 0000A800 00000000 00000000
Concatenate UA with IS (ua_size=3, is_size=1):
New UIS w/'interrupts' added : 0000A800 00000000 00000000 00000001
Interrupt-map-mask values: 0000F800 00000000 00000000 00000000

Comparing interrupt-map entries to this unit_interrupt_specifier:

Masked unit_int_specifier: 0000A800 00000000
Interrupt-map child spec : 0000A800 00000000
New unit_int_specifier   : 00000000 FF95A7A0 0000003A 00000001

found a cascading interrupt controller @ 0x00000000
cascadeStack[1] = 58 (ua_size = 2)

DEFAULT CATCH!, code=900 at   %SRR0: 00208ca4   %SRR1: 00003030
 ok
0 >


  The xServe freezes at a blank grey screen at this point, although up until then it is performing a ton of error-free operations.  I'm quite curious to know what the nature of the error is, and also whether or not it is possible to continue booting past this point via user intervention in the telnet session, seeing as it returns to a prompt after the last line.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on May 16, 2016, 06:39:43 PM

found a cascading interrupt controller @ 0x00000000
cascadeStack[1] = 58 (ua_size = 2)

DEFAULT CATCH!, code=900 at   %SRR0: 00208ca4   %SRR1: 00003030

It's the last few lines.  This actually indicates an error that prevents further booting.
Essentially it finds the interrupt controller and realizes it is an interrupt controller, but because there is no full driver for that north bridge (is that he Uni-north 2 they used in those?) then it fails to initialize. That's what the DEFAULT CATCH!,.... is.  That's actually an error message.
It's dropping to a default state where it won't go any further and returning to the open firmware prompt.   This is the Elf/Trampoline code I've mentioned elsewhere.  At this point in the process it is loading an initializing drivers from the rom and has not yet jumped to the actually ROM/toolbox startup.  The last thing this chunk of code does before jumping to the ROM/toolbox is to turn of Open Firmware.
This is actually the same thing that happens on a G5.  It does get this far and then hangs up.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on May 16, 2016, 08:16:24 PM
  I guess given your recent experiences with your G5, this is a much bigger problem than what has already been resolved or worked around for other systems - I don't know what you and Elliot have been scheming.  Hopefully I've been of at least a tiny bit of help.  I did find it quite interesting to read through that log and also learning about the telnet function.

  Do you have any further thoughts on the nature of this problem how it might be resolved?  How complex or large are these drivers anyway?
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: Protools5LEGuy on May 17, 2016, 11:25:43 PM

 I'm going to continue doing what I can to help the others with my Rev.1 xServe.  I'm getting a lot of very interesting information back from Elliot already.  While much of it is right over my head, I think I'm still of use, and I'm also brainstorming on various ways they can improve the entire process for everyone.  Elliot seems to be quite excited by what I've logged on my xServe already.  It's amusing seeing people happy about error codes.  If nothing else, I've learned far more about the Mac booting process over the last two days than I ever did in all my years prior.

Great to have all the details. Thank you all for you time
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: ELN on May 18, 2016, 01:51:23 AM
I think nanopico and I are going to have to deepen our understanding of the Trampoline. I see a rewrite in our future.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on May 19, 2016, 12:08:02 PM
And then lightning strikes and my brain bursts open.

I believe the thing preventing the xserve from booting is the external ata controller. Which is referred to as AppleKiwi.
As the drives on that controller are set for the boot device, even booting from CD will cause those to be looked at and since there are no OS 9 drivers for this controller then it fails.

The output from MacOS Plus shows that the initialization failure is on that controller's first disk.

This gives some direction to look now.  Because the overall architecture is the same as the MDD that support 9  and I believe that this AppleKiwi is the road block on this machine  (and I could be wrong). Well at least the current one we are running into.


Strike that note. I believe MacTron noted something about the PCI Bridge.  This is probably 100% correct.  Open Firmware will load the ROM and then the ROM will initialize stuff.  The ATA controllers are inititalizing (based on MacOS Plus output) and then it fails.  That would be the PCI Bridge.  Because those don't initialize the Keylargo chip won't initialize. So the hurdle is the PCI Bridge's. 

 So if  MacOS Plus is willing to do a  couple more things for us related to capturing some output from Open Firmware via telnet then that would be really awesome.

Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on May 19, 2016, 09:41:48 PM
Just PM'd you, nano.  I'll get you that output in the morning.

  I had a hard time questioning the ATA controller given that a number of third-party cards have used Promise chip variants.  Even if it wasn't a perfect match for the driver it shouldn't be a stretch for it to work.  I don't know if there is any firmware onboard the Promise hardware though that would need the right OS 9 hitches, as was typical of PCI expansion cards, or if it is all handled by the primary motherboard firmware.  I would hazard a guess that even if it can't boot from either ATA-6 channel, it may still be able to communicate with the drives as storage only.  The device tree appears to indicate that all the fancy drive monitoring functions are being handled by a completely separate chip also.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on May 20, 2016, 04:40:54 AM
Just PM'd you, nano.  I'll get you that output in the morning.

  I had a hard time questioning the ATA controller given that a number of third-party cards have used Promise chip variants.  Even if it wasn't a perfect match for the driver it shouldn't be a stretch for it to work.  I don't know if there is any firmware onboard the Promise hardware though that would need the right OS 9 hitches, as was typical of PCI expansion cards, or if it is all handled by the primary motherboard firmware.  I would hazard a guess that even if it can't boot from either ATA-6 channel, it may still be able to communicate with the drives as storage only.  The device tree appears to indicate that all the fancy drive monitoring functions are being handled by a completely separate chip also.
Thank you very much for your help with this.

There would be firmware required on the cards to boot 9.  Apple may have left it off as it may not be needed for X. I'm not real sure exactly, but when you get that output it may confirm or deny or confuse us more.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on May 20, 2016, 04:55:06 AM
And then lightning strikes and my brain bursts open.

I believe the thing preventing the xserve from booting is the external ata controller. Which is referred to as AppleKiwi.
As the drives on that controller are set for the boot device, even booting from CD will cause those to be looked at and since there are no OS 9 drivers for this controller then it fails.

The output from MacOS Plus shows that the initialization failure is on that controller's first disk.

This gives some direction to look now.  Because the overall architecture is the same as the MDD that support 9  and I believe that this AppleKiwi is the road block on this machine  (and I could be wrong). Well at least the current one we are running into.


Strike that note. I believe MacTron noted something about the PCI Bridge.  This is probably 100% correct.  Open Firmware will load the ROM and then the ROM will initialize stuff.  The ATA controllers are inititalizing (based on MacOS Plus output) and then it fails.  That would be the PCI Bridge.  Because those don't initialize the Keylargo chip won't initialize. So the hurdle is the PCI Bridge's. 

 So if  MacOS Plus is willing to do a  couple more things for us related to capturing some output from Open Firmware via telnet then that would be really awesome.

Correcting myself again. Looking over MacOS Plus pervious post, the pic bridges are not an issue. I looks like all the devices past it our initializing.  Something with the secondary ATA controller is the issue, but what is the question.

Has it been tried to just remove the four hard drives temporarily and try booting off the cd?
It does like the controller is recognized fine, but moving down to the disks is not. Not sure if this will get us any further, but it might.  Just a crazy idea.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on May 20, 2016, 08:20:09 AM
Correcting myself again. Looking over MacOS Plus pervious post, the pic bridges are not an issue. I looks like all the devices past it our initializing.  Something with the secondary ATA controller is the issue, but what is the question.

Has it been tried to just remove the four hard drives temporarily and try booting off the cd?
It does like the controller is recognized fine, but moving down to the disks is not. Not sure if this will get us any further, but it might.  Just a crazy idea.

  Anything I've done so far while setting up and testing my xServe right now has been with no hard drives in the slots, not even any external devices except the keyboard.  Perhaps it doesn't like having no drives?  Still I'm not convinced, but stranger things have happened in Apple's 'alternate dimension'.

  Further to my previous observation, what really is the 'hitch' that a system needs to consider a physical device controller, or device itself, a valid target for a boot device in OS 9?  I'm reminded of the absolutely maddening nonsense of the Apple-ROM'ed SCSI CD drives that were always needed to make booting automatic.  Third parties wrote around this with an extension but you still needed to be booted to a desktop before you could select a CD as the next boot device on reboot in this scenario.

  I'm also reminded of the SeriTek SATA PCI cards which were flashable with an alternate firmware to make them valid.  Everything seems to have to be 'just right' to play ball with Apple's environment choices.  I have flashed video cards, SCSI cards, and also did the established hack required to make certain vendors PCI device IDs on Realtek-based ethernet cards work with the available extension.  In an 'ocean' of possibility like this it might be hard to tell where any of our problems with the xServe truly sit, but it will be fun and educational trying.

  I'll be back in a few minutes with your requested output (the revised version).
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on May 20, 2016, 08:38:11 AM
Correcting myself again. Looking over MacOS Plus pervious post, the pic bridges are not an issue. I looks like all the devices past it our initializing.  Something with the secondary ATA controller is the issue, but what is the question.

Has it been tried to just remove the four hard drives temporarily and try booting off the cd?
It does like the controller is recognized fine, but moving down to the disks is not. Not sure if this will get us any further, but it might.  Just a crazy idea.

  Anything I've done so far while setting up and testing my xServe right now has been with no hard drives in the slots, not even any external devices except the keyboard.  Perhaps it doesn't like having no drives?  Still I'm not convinced, but stranger things have happened in Apple's 'alternate dimension'.

  Further to my previous observation, what really is the 'hitch' that a system needs to consider a physical device controller, or device itself, a valid target for a boot device in OS 9?  I'm reminded of the absolutely maddening nonsense of the Apple-ROM'ed SCSI CD drives that were always needed to make booting automatic.  Third parties wrote around this with an extension but you still needed to be booted to a desktop before you could select a CD as the next boot device on reboot in this scenario.

  I'm also reminded of the SeriTek SATA PCI cards which were flashable with an alternate firmware to make them valid.  Everything seems to have to be 'just right' to play ball with Apple's environment choices.  I have flashed video cards, SCSI cards, and also did the established hack required to make certain vendors PCI device IDs on Realtek-based ethernet cards work with the available extension.  In an 'ocean' of possibility like this it might be hard to tell where any of our problems with the xServe truly sit, but it will be fun and educational trying.

  I'll be back in a few minutes with your requested output (the revised version).

I'm not convinced of anything related to this yet.  I'm just trying to eliminate possibilities and try to identify that magical combination that makes it all work.

OS 9 looks to the drives very early on to find the boot block which tells which folder is blessed and what the debugger is if there is one and to load the finder (or something else in it's place). 
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on May 20, 2016, 09:19:37 PM
Here is the telnet log from the last testing nanopico asked me for:

Code: [Select]
Last login: Mon May 16 13:58:30 on ttys000
Hyper-PowerBook-G4:~ administrator$ telnet 192.168.0.250
Trying 192.168.0.250...
Connected to 192.168.0.250.
Escape character is '^]'.
 ok
0 > printenv
-------------- Partition: common -------- Signature: 0x70 ---------------
little-endian?          false                false


Open call - nvram already open
 ok
0 > devalias
pci0                /pci@f0000000
agp                 /pci@f0000000
pci1                /pci@f2000000
pci2                /pci@f4000000
ui2c                /uni-n/i2c
ui2c-serial         /uni-n/i2c/cereal
keyboard            /pseudo-hid/keyboard
mouse               /pseudo-hid/mouse
sound               /pseudo-sound
eject-key           /pseudo-hid/eject-key
nvram               /nvram
enet                /pci@f4000000/ethernet
fw                  /pci@f4000000/firewire
bridge0             /pci@f2000000/@d
pci                 /pci@f2000000/@d
bridge              /pci@f2000000/@d
usb0                /pci@f2000000/@d/usb@8
usb1                /pci@f2000000/@d/usb@9
fwx                 /pci@f2000000/@d/firewire
enetx               /pci@f2000000/@d/ethernet
mac-io              /pci@f2000000/@d/mac-io@7
mpic                /pci@f2000000/@d/mac-io@7/interrupt-controller
hd                  /pci@f2000000/AppleKiwi@15/ata-6@0/disk@0
cd                  /pci@f2000000/@d/mac-io@7/ata-4@1f000/disk@0
zip                 /pci@f2000000/@d/mac-io@7/ata-3@20000/disk@1
ide0                /pci@f2000000/@d/mac-io@7/ata-3@20000/disk@0
ide1                /pci@f2000000/@d/mac-io@7/ata-3@20000/disk@1
ultra0              /pci@f2000000/AppleKiwi@15/ata-6@0/disk@0
ultra1              /pci@f2000000/AppleKiwi@15/ata-6@1/disk@0
scca                /pci@f2000000/@d/mac-io@7/escc/ch-a
sccb                /pci@f2000000/@d/mac-io@7/escc/ch-b
ki2c                /pci@f2000000/@d/mac-io@7/i2c
ki2c-serial         /pci@f2000000/@d/mac-io@7/i2c/cereal
via-pmu             /pci@f2000000/@d/mac-io@7/via-pmu
rtc                 /pci@f2000000/@d/mac-io@7/via-pmu/rtc
pi2c                /pci@f2000000/@d/mac-io@7/via-pmu/pmu-i2c
ultra2              /pci@f2000000/AppleKiwi@1b/ata-6@0/disk@0
ultra3              /pci@f2000000/AppleKiwi@1b/ata-6@1/disk@0
bridge1             /pci@f2000000/@11
lm87                /uni-n/i2c/lm87
kgpio               /pci@f2000000/@d/mac-io@7/gpio
keyswitch           /pci@f2000000/@d/mac-io@7/gpio/@c
monitor             /pci@f2000000/@d/mac-io@7/gpio/@12
indicator           /pci@f2000000/@d/mac-io@7/gpio/@15
led                 /pci@f2000000/@d/mac-io@7/gpio/@20
9554-0              /pci@f2000000/@d/mac-io@7/via-pmu/pmu-i2c/@140
9554-1              /pci@f2000000/@d/mac-io@7/via-pmu/pmu-i2c/@142
9554-2              /pci@f2000000/@d/mac-io@7/via-pmu/pmu-i2c/@144
9554-3              /pci@f2000000/@d/mac-io@7/via-pmu/pmu-i2c/@146
9554-M              /pci@f2000000/@d/mac-io@7/via-pmu/pmu-i2c/@148
last-boot           /pci@f4000000/ethernet@f
screen              /pci@f0000000/ATY,Rage128Ps@10
 ok
0 > dev /pci@f2000000/AppleKiwi@15 .properties
vendor-id             

Open call - nvram already open
 ok
0 > dev /pci@f2000000/AppleKiwi@15/ata-6@0 .properties
name                    ata-6

Open call - nvram already open
 ok
0 > dev /pci@f2000000/AppleKiwi@1b .properties
vendor-id             

Open call - nvram already open
 ok
0 > dev /pci@f2000000/AppleKiwi@1b/ata-6@0 .properties
name                    ata-6

Open call - nvram already open
 ok
0 > dev /pci@f2000000/pci-bridge@d/mac-io@7/ata-4@1f000 .properties
name                    ata-4

Open call - nvram already open
 ok
0 > dev /pci@f2000000/pci-bridge@d .properties
vendor-id             

Open call - nvram already open
 ok
0 > dev /pci@f2000000/pci-bridge@11 .properties
vendor-id             

Open call - nvram already open
 ok
0 >

  This is mainly commands listing devices.  Note the legacy presence of an alias for a Zip drive device.  I actually tried once in the past to hook up a Zip drive to the cable in one of the drive caddies.  For some reason this made the ATA controller VERY unhappy! ;D
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on May 24, 2016, 02:52:02 PM
  I'd been chatting with nanopico about the situation with the ATA controller(s).  I went back and tested a boot using ELN's original commands, but this time I used an external firewire DVD drive on a rear port instead of the the internal optical drive.

  When I had first tried this configuration months ago I didn't have the benefit of the telnet logging to know exactly what the system was doing while showing only a grey screen.  Now it is clear that a lot more is going on when using the firewire drive to boot the CD versus the internal drive.  So much more that it exceeded the character limit in the messaging window of the forum when I tried to send it to nanopico!  I had to break it up into multiple messages.  As such I won't post it here in whole or part for the moment.  It would be better just to have nanopico comment on it and show relevant log snippets if anything.

  I don't know where that gets us but it certainly was interesting!
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on May 24, 2016, 03:16:03 PM
The stuff MacOS Plus generated is daunting to say the least.  But I am going to go over it tonight.
This plus what ELN and I have deciphered with the ROM/trampoline stuff is getting interesting.
I'll update that other post about the trampoline code tonight too.

Oh so many cool things happening.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on May 26, 2016, 07:55:42 AM
If someone has a Sonnet Tempo RAID ATA100 and want's to help please contact me.
We need to locate one for some comparison testing.  If you are willing to sell me or MacOS Plus one awesome.  If not and you are willing to just get us some information from it that would be awesome too.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 13, 2016, 11:16:52 AM
Just got a g4 xserve.
It has a few issues that I will have to resolve such as a flakey cd drive (which MacOS Plus was kind enough to point out to me prior to it arriving that this is common), and no hard drives.  The drive sleds are there but I just need to actually install disks.
One of the USB ports is physically destroyed.

This should make things move a little faster. 
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: DieHard on June 13, 2016, 03:24:07 PM
Quote
One of the USB ports is physically destroyed.

Before powering up, remember that manged USB ports often create a hard short that will not allow the unit to post,  so pick out all the broken metal pieces with small needle nose pliers and then you can fill the square hole will hot glue from a crafts gun, this stops any accidental use of a bad USB port that could short or damage the MB
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 13, 2016, 06:39:40 PM
Quote
One of the USB ports is physically destroyed.

Before powering up, remember that manged USB ports often create a hard short that will not allow the unit to post,  so pick out all the broken metal pieces with small needle nose pliers and then you can fill the square hole will hot glue from a crafts gun, this stops any accidental use of a bad USB port that could short or damage the MB

Thank you for the insight, that's great advice I will definitely follow.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 13, 2016, 09:31:49 PM
Slightly off-topic but in reference to the last couple posts:

  It's really annoying this machine only has two USB ports.  I couldn't understand why they chose not to put one in the front panel to compliment the extra firewire port at least.  I'm considering adding a USB PCI card and some sort of front-bay port panel to my primary OS X Xserve rather than risking dealing with a potentially flaky USB hub.  I'm mostly interested in having another port or two for maintenance purposes and for temporary attachment of USB storage keys or external hard drives.

  While we're talking USB on the Rev.1 Xserve, I've successfully installed a bluetooth USB transceiver and an Apple bluetooth keyboard (the 3-cell edition).  It works just fine in 10.5.  I've never been a big fan of bluetooth mice but I suppose I could add one in order to free-up the other USB port.

  I realize the bluetooth stuff won't carry over to the OS-9-on-Xserve project, but I'm trying to make the best OS X config possible on my first Xserve because it will make for a very useful server which will help a lot with many other projects.  My second Xserve machine is getting the 'OS 9 treatment', or more a 'beat-down' so far.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 17, 2016, 12:30:10 PM
Currently working on my xserve.

Got passed the original boot error we were seeing.  Now hitting another one, but may get passed that soon too.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 17, 2016, 01:53:33 PM
You can now add the xserve to the list of bootable machines.

(https://pvdipa.dm2304.livefilestore.com/y3mJDBYs5yfa6bYBznR_0OnjdOLHXPKwoC8UY6UbBMvoLwGI4_CF7GXnci1l9Npwv6uHKbuHNgi0aPa_5yvGgZeRgXJi8sWXyTd-ZQGpE_ZmOJ-U6wqALuPq6CU9c5YJTgAEeYQYLE7jyZxb_GqphRLzJ2Ft9dLFcr8VhzbzUgrwtU?width=660&height=495&cropmode=none)

(https://pvdjpa.dm2304.livefilestore.com/y3mt6azZ4aWTlrWYrv3ZVuXWxtpaoFtaRTlfVrDSjnt0pjv_znTasEbos343H5C_nwwBz2xDggfamsVfVlSGXRfKHDj_yROy1M4tv6EdXgAW68DThdUO_DQOizucMR-YlZRmlCreW_MYTGFQA0Bofgy2SU6MpWm9XKMTXXfwQTmWn0?width=660&height=495&cropmode=none)

Pardon the crappy pictures  Best I could do at the moment.
I got a video too that I will try to get up.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 17, 2016, 02:30:10 PM
Holy sh*t!  What do I have to do to try this when I get home tonight?!?

  We spent a while 'battling' the ATA controller - did you finally manage to fully disable that blasted "Kiwi"?  Did you have to disable anything else?  I can hardly wait to open up System Profiler on my machine to see how all the hardware reports itself.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on June 17, 2016, 02:45:49 PM
You can now add the xserve to the list of bootable machines.

WOW!

;D ;D ;D ;D ;D ;D ;D ;D ;D ;D
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 17, 2016, 03:55:54 PM
Holy sh*t!  What do I have to do to try this when I get home tonight?!?

  We spent a while 'battling' the ATA controller - did you finally manage to fully disable that blasted "Kiwi"?  Did you have to disable anything else?  I can hardly wait to open up System Profiler on my machine to see how all the hardware reports itself.

The damn kiwi.  Yes we were on the right track. After a whole lot of typing I figured it out.
So once it boots you have not hard disks what so ever, after getting over the ata controller it booted with no other issues or changes.

So big step just have to get the controller to work though so it's useful.

On mine it did boot really slow but I equate that to the cd drive being stupid.
So here is what you do.

Code: [Select]
" /pci@F2000000/AppleKiwi@15" find-package drop delete-node
" /pci@F2000000/AppleKiwi@1b" find-package drop delete-node
boot cd:,\\:tbxi
The last line is how I booted off the cd.  How ever you did it before will work too.

this deletes it and takes care of removing all the cross references (which is a lot) to other hardware.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 17, 2016, 05:26:40 PM
That's really interesting if you could boot from the internal optical drive over the ATA4 bus because that means my idea to put an SSD in a conversion carrier should work too.  When I get them in the mail I'm going to try that, made easier by the fact I should be able to boot the CD from my external FW DVD drive.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 17, 2016, 06:04:48 PM
That's really interesting if you could boot from the internal optical drive over the ATA4 bus because that means my idea to put an SSD in a conversion carrier should work too.  When I get them in the mail I'm going to try that, made easier by the fact I should be able to boot the CD from my external FW DVD drive.

Yup that will work.

I have now added to my list of things to do is to get that controller working in 9. 
I have some ideas, but I've got some research to do first.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 17, 2016, 10:45:15 PM
  I was so excited about trying this out I went straight to the machine after work.  I booted the original version of the "Universal 9.2.2" disc from the external FW DVD drive.  In an ironic twist (because of what I'd just been saying about ATI), when it got to the desktop it seemed to get hung up, but pressing "cmd-opt-esc" popped up a force-quit dialog for "ATI Video Accelerator".  After quitting this it quickly finished loading to the desktop successfully!!!!!!!

  The Rage128 Pro AGP video card I'm using wasn't getting along with that one extension, but at least that is an entirely separate and isolated issue.  I can sort that out later.  I'm still getting proper video and full access to resolutions.  The max for this card on VGA output is 1280x1024 at millions of colours.  (It has 16MB VRAM.)

  Next I ran ASR to install to an external SSD on another firewire port.  This ran quite smoothly.  Rebooted to the SSD with extensions off - WORKED!  Cleaned up extensions and control panels (pulled all the ATI ones for now), rebooted - WORKED!!!!!!  IT'S ALIVE!!!!!

  Not only is this machine very fast, even without the video acceleration and a very old video card, but the multiprocessing is WORKING!!!!!!!!  Built-in ethernet works, time server sync works, file sharing enabled (I will test this further later), and internet access WORKS!!!  I managed to download Classilla 9.3.3 using Internet Explorer (obviously I could have just copied it from somewhere else, but that wasn't the point).

  Now that I have a usable and fast browser on this Xserve I thought it would be most appropriate that I post this message directly from the keyboard of this machine.  History, folks!  This is so AWESOME!!!!!!!!!  I feel honored!  This is a huge dream come true for me personally because I originally bought this machine years ago with the hope that some day this would actually work.  I never thought that this long after the official dropping of OS 9 support I would be sitting here running this FOR REAL!  I don't know what else to say - I'm ecstatic!!!!!!!!! ;D ;D ;D ;D ;D

  I will continue testing to see if anything else doesn't work aside from the main ATA controller.  This machine is so simple there isn't really much left that could go wrong.  We'll continue to work at this and keep you all posted!

P.S.  Just before I settle down and go to bed I have one thing to add.  I decided to swap out the AGP Rage128 Pro and AGP riser for a Radeon 7000 PCI 32MB and the PCI riser just to see how a later card would work.  The Radeon plays nice with all the extensions, seems to have acceleration working, and gives me access to 16:9 ratio resolutions for the LCD I have connected.  Now I have a crisp, native 1440x900 and better scolling.  When I locate my Cinebench installer I will give it a run at benchmarking the performance.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 18, 2016, 05:06:12 AM
  I was so excited about trying this out I went straight to the machine after work.  I booted the original version of the "Universal 9.2.2" disc from the external FW DVD drive.  In an ironic twist (because of what I'd just been saying about ATI), when it got to the desktop it seemed to get hung up, but pressing "cmd-opt-esc" popped up a force-quit dialog for "ATI Video Accelerator".  After quitting this it quickly finished loading to the desktop successfully!!!!!!!

  The Rage128 Pro AGP video card I'm using wasn't getting along with that one extension, but at least that is an entirely separate and isolated issue.  I can sort that out later.  I'm still getting proper video and full access to resolutions.  The max for this card on VGA output is 1280x1024 at millions of colours.  (It has 16MB VRAM.)

  Next I ran ASR to install to an external SSD on another firewire port.  This ran quite smoothly.  Rebooted to the SSD with extensions off - WORKED!  Cleaned up extensions and control panels (pulled all the ATI ones for now), rebooted - WORKED!!!!!!  IT'S ALIVE!!!!!

  Not only is this machine very fast, even without the video acceleration and a very old video card, but the multiprocessing is WORKING!!!!!!!!  Built-in ethernet works, time server sync works, file sharing enabled (I will test this further later), and internet access WORKS!!!  I managed to download Classilla 9.3.3 using Internet Explorer (obviously I could have just copied it from somewhere else, but that wasn't the point).

  Now that I have a usable and fast browser on this Xserve I thought it would be most appropriate that I post this message directly from the keyboard of this machine.  History, folks!  This is so AWESOME!!!!!!!!!  I feel honored!  This is a huge dream come true for me personally because I originally bought this machine years ago with the hope that some day this would actually work.  I never thought that this long after the official dropping of OS 9 support I would be sitting here running this FOR REAL!  I don't know what else to say - I'm ecstatic!!!!!!!!! ;D ;D ;D ;D ;D

  I will continue testing to see if anything else doesn't work aside from the main ATA controller.  This machine is so simple there isn't really much left that could go wrong.  We'll continue to work at this and keep you all posted!

P.S.  Just before I settle down and go to bed I have one thing to add.  I decided to swap out the AGP Rage128 Pro and AGP riser for a Radeon 7000 PCI 32MB and the PCI riser just to see how a later card would work.  The Radeon plays nice with all the extensions, seems to have acceleration working, and gives me access to 16:9 ratio resolutions for the LCD I have connected.  Now I have a crisp, native 1440x900 and better scolling.  When I locate my Cinebench installer I will give it a run at benchmarking the performance.

For the most part the only issues that should be seen are ones that would have occurred with the MDD's. 
I believe MacTron originally pointed out they are pretty much the same.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 18, 2016, 09:22:27 AM
  This morning I installed 1.5GB of RAM and ran the ATI 2005 updater to bring the extensions to their final revisions.  Booting also works from the front-panel firewire port.

  Next I thought I would try seeing just how close this machine really is to an MDD by trying to put it to sleep and wake it.  Selecting sleep brought up a dialog warning that it couldn't proceed until the case-closed switch was engaged.  This is really cool because it recognizes that function through the power management unit and the front panel controls.  Since I was running with the case open I simply held down the switch with my finger and tried again.  It went to sleep properly!  Then I pressed the mouse button to wake it again - it woke!!!  (It also turns out letting go of the switch will wake it too, so the system can respond to numerous inputs for wake.)  What didn't work was that the sleep and wake cycle lost the firewire hard drive creating a condition that required a restart.  At first I thought this was because it had been running on FW bus power and didn't initialize properly when the power came back.  So I tried powering it separately but it still trips up the drive.  I don't think this is an incompatibility issue with the Xserve - it's simply what would have occurred potentially on other machines too.  Not a deal breaker because I normally don't sleep any of my OS9 machines.  Once I get the conversion carrier for the optical drive bus so I can install the SSD there I have a feeling this issue will go away.

  One last note before I leave for the day - Not really a surprise, but the front panel CPU activity guages don't do anything.  I don't know what data source actually drives them.  They may very well never work but we'll see.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: ELN on June 18, 2016, 06:53:07 PM
Congratulations both of you. Beautiful work!
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 18, 2016, 10:02:37 PM
  Thanks to member Mat I was able to quickly download Cinebench 2003 for Mac so I could test the functional state of the ATI drivers with the Radeon 7000 PCI card in the OS 9 Xserve.  Running the test proved two things - The acceleration is operational as it appeared to be, and second that the Radeon 7000 kinda sucks (which I knew anyway).  The important thing is it works and I can move on to a better card when I get hold of one.  Here is the report output from Cinebench:

Code: [Select]
CINEBENCH 2003 v1
****************************************************

Tester           : MacOS Plus

Processor        : Xserve G4 Rev.1
MHz              : 1.0GHz 2MB L2
Number of CPUs   : 2
Operating System : Mac OS 9.2.2

Graphics Card    : Radeon 7000 PCI 32MB
Resolution       : 1440x900
Color Depth      : Millions

****************************************************

Rendering (Single   CPU): 94 CB-CPU
Rendering (Multiple CPU): 177 CB-CPU

Multiprocessor Speedup: 1.88

Shading (CINEMA 4D)                : 113 CB-GFX
Shading (OpenGL Software Lighting) : 321 CB-GFX
Shading (OpenGL Hardware Lighting) : 242 CB-GFX

OpenGL Speedup: 2.84

****************************************************

  The super-cool thing is that the test was taking advantage of the multiprocessing and reporting the afforded performance boost!  This was also an important proof of concept on the Xserve platform under OS 9 - that the multiprocessing isn't an non-functional facade.  It reports and works properly!

  Also as part of this test I downloaded Cinebench with the OS X Xserve first so I could test file sharing.  I was able to mount the X-drive on the 9-machine and copy the file over.  Cool - file sharing works!  I was kinda cute really watching two Xserves chatting with one another.  Not something may people would have ever witnessed.  Two roaring monsters they are, but family all the same!

Thanks again, Mat!
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 18, 2016, 10:10:40 PM
One last thing for the night:

  Does anyone know if there is a preferential slot ordering for the RAM DIMMs in the Xserve G4?  At the moment I have three 512MB DIMMs installed starting from the left-most slot.  It probably doesn't matter hugely but I'd prefer to install them in the order it addresses them without skipping a slot.  (If we ever get access to 2MBs RAM in OS 9 I won't have to think about that because all the slots would be full anyway!)

  I'm beginning to wonder if I should be renaming this machine a "9serve" - take that, Apple!  (I claim all rights to that name!!!!  Mwahahahahah!)
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: DieHard on June 18, 2016, 11:19:56 PM
This is so excellent !  I scraped 3 units about 4 months ago. You guys truly suck :)

My lack of faith bit me in the ass on this one. This is a first for sure. Xserve running OS 9 !!!
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: mrhappy on June 19, 2016, 12:07:18 AM
Wow, this is crazy cool!! ;D
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 19, 2016, 07:38:19 AM
  Hah, DieHard, you're really going to hate me when I post pics of the two machines running side-by-side!  Don't worry, we'll put the 'religion' back in you.  Perhaps I'll even test a pci expansion chassis and see just how big a monster I can make out of this!  I guess I'm now in market for more Sonnet MDX upgrades.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on June 19, 2016, 09:02:56 AM
This 66 Mhz 64 bits PCI bus, it's double the bandwidth of the most capable Macs.

Imagine a four SSDs raid with the  Seritek 64 bits SATA card (that claims that can work at 66 Mhz!).
Imagine a nVidia 4600 Ti fitted inside this machine.
Imagine the included serial port works for MIDI data.
Imagine a Sonnet 7447 @ 1.8 dual, empowering this machine.
Imagine the three ATA 133 modules working.

You may say I'm a dreamer
But I'm not the only one.
LOL.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: Metrophage on June 19, 2016, 09:32:40 AM
Imagine the included serial port works for MIDI data.

Good thinking - I have never heard of people actually using the RS232 ports on these for anything. I am curious to know what might need doing to get them working
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 19, 2016, 11:29:06 AM
  I was just going to ask about that serial port myself.  Not sure it can be used as we want because it was set up as a diagnostic terminal interface that's supposed to work automatically, much as is typical on most other server platforms.  I can at least tell you OS 9 doesn't show its presence as a device at all.  I don't think it was ever meant to be freely accessable that way, but we'll see.

@MacTron - Keep dreaming big - I'm right on the same page with you!
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 19, 2016, 11:34:35 AM
I was under the impression that the serial port was for receiving signals from UPS to be notified of shutdown so it is probably connected directly to the emu and probably not accessible.
But I could be wrong on that.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 19, 2016, 02:06:24 PM
  The documentation said something about external management via a serial terminal.  This would allow access to the machine under certain conditions without monitor or video card.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 19, 2016, 08:33:55 PM
Going to investigate.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 19, 2016, 09:06:19 PM
  More testing tonight - second PCI bus works, not that there's any reason it should not have.  I put in an Adapted AHA-2940U2W SCSI card just to see if it was recognized.  The only thing it caused, and exactly as it should have, was the start-up disk detection at boot took an extra-long time to try the FW SSD because it was obviously scanning all the SCSI IDs for possible drives.  After it got through that it went ahead and booted as normal.  The card shows up in System Profiler.  Later I will actually attach a drive and see if it behaves.

  Next up I hooked up my 4-slot 32-bit Magma PCI-PCI expansion chassis.  This is a rack-mountable version, which will be great if I decide to permanently pair it with this machine.  It is also the older type with the big low-density cable connectors.  I moved the SCSI card into the chassis and booted.  It recognizes the SCSI card there too!  The boot from the FW SSD completed exactly the same way with no indication of lag.  The only thing I don't know is if using 5-volt-only cards in the chassis is possible.  I will mess around with that more later.

  Finally, just to throw it a challenge, I put the 64-bit LSI fibre channel card this machine originally came with into the remaining slot in the riser (next to the Magma bridge card).  The machine took longer to get through the start-up disk detection, again because it was now scanning the fibre channel bus for a link and drives.  After the long pause it again booted as normal!  System Profiler shows the card present.  I don't know if it would actually communicate with an FC chassis under OS 9 though.  Unfortunately I don't have any other FC gear around any longer to test that with.

MagmaSlots output:
Code: [Select]
                       Magma Slot Peek
                       ===============

PCI Slot Name : $3x4 (Devices:device-tree:pci:pci-bridge:pci-bridge:pci-bridge)
   Card Name : pci-bridge
   Device Type : pci
   Board Version : 6
   Board Vendor ID : 1011
   Bus Slot Number: 4; on PCI Bus Number: 3

PCI Slot Name : $4x7 (Devices:device-tree:pci:pci-bridge:pci-bridge:pci-bridge:ADPT,2940U2B)
   Card Name : ADPT,2940U2B
   Device Type : scsi-2
   Board Model : ADPT,1757800-00
   Board Version : 1
   Board Vendor ID : 9005
   Bus Slot Number: 7; on PCI Bus Number: 4

Look at all those PCI bridges!

System Profiler output:
Code: [Select]
Software overview
Serial number: XB2270GNLZF
Mac OS overview
Finder: 9.2
System: 9.2.2  US
Active enabler: Mac OS ROM 10.2.1 (Generic)
QuickTime: 6.0.3
CarbonLib: 1.6.1
File sharing: is on
Multiple Users: Not installed
Note: No startup disk was selected.
Memory overview
Disk cache: 8160K
Virtual memory: is off
Built-in memory: 1.50 GB
Number of empty RAM slots: 1 (DIMM0/J21)

Location            Size           Memory type
DIMM1/J22   512 MB   PC2600U-30330
DIMM2/J23   512 MB   PC133 CL3
DIMM3/J20   512 MB   PC133 CL3
Video memory: 32 MB Built-in display in use
Backside L2 cache: 2 MB
Hardware overview
Machine ID: 406
Model name: RackMac1
Keyboard type: Apple Pro Keyboard
Processor info: PowerPC G4
Machine speed: 1000 MHz
Processors: 2
Nanokernel version: 2.28
Nanokernel pool extends: 11
Nanokernel scheduled CPUs:2
uni-n: 36
Network overview
Ethernet built-in Link: up Speed: 1 Gbps Duplex: full
Modem
Name:
Protocol:
Version:
Status: No Apple modem found.
Open Transport
Installed: Yes
Active: Yes
Version: 2.8.3
AppleTalk
Installed: Yes
Active: Yes
Version: 61
File sharing: is on
Default AppleTalk zone: Not available
Active network port(s): Ethernet built-in
This network: 65280
This node: 128
Router: <not available>
Hardware Address: 00.03.93.b5.e3.f2
TCP/IP
Installed: Yes
Active: Yes
Version: 2.8.3
Personal Web Sharing: is off
USB Printer Sharing: Not installed
Netmask: 255.255.255.0
IP address: 192.168.0.194
Default gateway address: 192.168.0.1
Domain:
Name server address: 8.8.8.8
Production information
ROM revision: $77D.45F6
Boot ROM version: $0004.44f1
Mac OS ROM file version: 10.2.1
Serial number: XB2270GN-LZF-0000
Software bundle: Not applicable
Sales order number: Not applicable

Fun!
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 19, 2016, 09:39:56 PM
Last thing for tonight:

  I stumbled upon an ATI Radeon 9200LE 128MB PCI video card I'd completely forgotten I had.  Obviously I wanted to try this in place of the 'lowly' Radeon 7000 I've been testing with so far.  But why put it in the single-slot riser when there is much more fun to be had?

  I already know that the as-built config from Apple with the 8500 PCI video card placed the card in the 2-slot riser (because a Broadcom 64-bit 66MHz gigabit ethernet card took over the single-slot location).  This meant, as it should be, that a PCI video card should be detected on any PCI bus or bridge and just work.  Performance would be less potentially, but wouldn't it make for a neat experiment to try a video card in the Magma chassis?

  So the 9200 went into the Magma.  It initiallized and displayed Open Firmware properly so I continued with the experiment.  It booted through to the desktop without a hitch!  It even supports a higher refresh rate at 1440x900 than the 7000 card did.

  I've learned the hard way in the past that one of the most effective ways of determining the stability of an expansion chassis setup is to put the primary video card in it.  Given that this worked through this older chassis even, the PCI bus seems to be no issue at all on the Xserve with OS 9.  I'll try a SCSI card again later with some heavy disk activity though so I can be certain.

  Now if only I had a functioning ProTools TDM on here.  I've really got to get my authorization disk issue sorted out.

  Afterward I moved the card from the chassis to the single-slot to compare Cinebench stats.  One of the figures had taken quite a dent from being in the lesser-capable slot prior.  Now the Stats were where they should be.  Interestingly they are virtually the same as for the 7000.  I know the 9200 is also kinda crappy too, but it has to be better in ways this particular benchmarking doesn't record.  I'm pleased it works without issue though.  It's probably a decent and affordable choice for anyone looking to outfit themselves with an Xserve G4 on OS 9 and will work without accessory power feeds or taped pins as with some of the more capable AGP cards.  (It's difficult to get hold of an AGP-AGP riser for these machines anymore anyway.)
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 20, 2016, 07:40:53 PM
  I decided since I was trying to test as many configurations as possible that I would finally take the potentially risky step of seeing if an ADC-type AGP video card would safely function in the Xserve AGP riser.  The only slot pins that pass through to the ADC port are data lines for the ADC USB bus and should not be of consequence in a 4x AGP slot where those pins aren't assigned in the generic slot specification.  I assumed this carried over to the PCI spec also such that no pins should be in conflict.  The ADC power doesn't go through the main section of the slot so it is safely physically isolated.  (Any 8x card probably wouldn't require the same pin taping/cutting as for ADC-slot machines and would likely run at 4x automatically, but they wouldn't have OS 9 support anyway.)  I went on the assumption that it was unlikely Apple did anything out of spec for this slot because the same pins were used for both riser types and had to be safe for any standard PCI card too.  Still, I've learned from experience not to trust Apple to not screw around with standards, but I considered the risk to be low in this case.

  I went with the first OS 9-compatible ADC video card I found that would physically fit, a GeForce2 MX 32MB.  It actually worked without any trouble, aside from the fact it defaults to a very low resolution until it boots once properly with drivers.  After that I could set the same resolution I needed before - 1440x900.  It is connected to the VGA output directly rather than through an adapter off the ADC port.  Cinebench shows a substantial increase in OpenGL performance with this lowly card, proving that AGP communication with acceleration enabled makes all the difference over PCI in this machine.  I guess that should come as no surprise.

  Obviously the only thing to keep in mind is that you can't directly connect an ADC monitor without an adapter to power it and provide the USB link.  Conversion to DVI or VGA with adapters should work because the ADC power and USB lines aren't needed for that.  This means a vastly increased pool of accessible video cards for anyone trying to piece together one of these Xserves, especially for those looking at supporting both OS's in a dual-boot configuration.

  Anyone else ready to try their Xserve yet?
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: DieHard on June 21, 2016, 10:31:11 AM
 :-X :-X :-X :-[

 >:( >:(

All of mine were sent to the scrapper, but the CPU boards live in my MDDs. 

If I get another one in I will test Cubase and some other DAWs.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on June 21, 2016, 11:49:46 AM
All of mine were sent to the scrapper, but the CPU boards live in my MDDs. 

If I get another one in I will test Cubase and some other DAWs.

I'm anxious buy an xServe also. But after buying the two HP's displays my budget to this kind of stuff is empty for a couple of months at least ...  :'(

While, I will wait to if a solution for the ATA 133 module is found.

This is by far, the more important unsupported G4 Project.

Congratulations and thanks to ALL.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 21, 2016, 08:06:39 PM
  Keep in mind that while the ATA100 version of the Promise chip, PDC20270, had a functional OS 9 equivalent ROM, the ATA133 PDC20271 never did.  This would make it far more likely that a stock Xserve "Tray-load" with the ATA100 can be made to work than the faster one in the Xserve "Slot-load".  Not that it's impossible, but Sonnet did go with a completely different vendor's chipset for their ATA133 RAID card for some reason.  At the very least you might be able to simply swap an ATA100 bridge board into a "Slot-load" machine if we can get that controller working in the first place.  Otherwise just go with a PCI card for now.

  On that note, a reminder to all that we're still seeking a Sonnet Tempo RAID ATA100 PCI card for testing on this project.  Also, if anyone scraps an Xserve "Slot-load" I'm interested in acquiring the front bezel plate and possibly some other bits.

Okay, time for some pictures... 'cause it happened!  Check out the epic unintended lens flares:

Xserve meets 9serve - they seem to have the same taste in websites!  (TenFourFox vs Classilla - PPC browsing at its finest.)  They also like similar keyboards.
(http://i1262.photobucket.com/albums/ii607/SpawnedFromTheEther/CAM00390.jpg)

Xserve "Tray-load" - but wait, swapped in a vastly better slot-load DVD drive.  Four-channel fan speed controller tamed the noisy beast!  Bluetooth keyboard on ancient Kensington USB BT dongle.
(http://i1262.photobucket.com/albums/ii607/SpawnedFromTheEther/CAM00391.jpg)

9serve "Tray-load" - also with a slot-load drive (no faceplate - 'borrowed' from Powerbook Ti).  Booting SSD from front firewire.  Lacie USB floppy and Macally 'floating-apple' mouse.
(http://i1262.photobucket.com/albums/ii607/SpawnedFromTheEther/CAM00392.jpg)

Bestest desktop picture ever!   "G4 WITH VELOCITY ENGINE"  Really awesome but makes no sense at all - just like most Apple marketing!
(http://i1262.photobucket.com/albums/ii607/SpawnedFromTheEther/CAM00393.jpg)

Xserve "About This Mac":
(http://i1262.photobucket.com/albums/ii607/SpawnedFromTheEther/CAM00394.jpg)

9serve "About This Computer":
(http://i1262.photobucket.com/albums/ii607/SpawnedFromTheEther/CAM00395.jpg)
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 22, 2016, 05:39:16 AM
  Keep in mind that while the ATA100 version of the Promise chip, PDC20270, had a functional OS 9 equivalent ROM, the ATA133 PDC20271 never did.  This would make it far more likely that a stock Xserve "Tray-load" with the ATA100 can be made to work than the faster one in the Xserve "Slot-load".  Not that it's impossible, but Sonnet did go with a completely different vendor's chipset for their ATA133 RAID card for some reason.  At the very least you might be able to simply swap an ATA100 bridge board into a "Slot-load" machine if we can get that controller working in the first place.  Otherwise just go with a PCI card for now.

I was digging around on this, I couldn't find anything on the Sonnet ATA Raid 100 on their site, but I did find the ATA Raid 133 and it was supported as a bootable device in OS 9.  So their may be hope yet on both of those.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on June 22, 2016, 06:51:12 AM
At the very least you might be able to simply swap an ATA100 bridge board into a "Slot-load" machine if we can get that controller working in the first place.
Interesting idea.
I was digging around on this, I couldn't find anything on the Sonnet ATA Raid 100 on their site, but I did find the ATA Raid 133 and it was supported as a bootable device in OS 9.  So their may be hope yet on both of those.
Even better idea :)

We have to face a several issues, find the firmware with Mac os 9 drivers compatible with this ATA133 bridge board  and know how to install them inside the board  (I guess we have to reflash an EPROM or something similar)
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 22, 2016, 07:23:40 AM
At the very least you might be able to simply swap an ATA100 bridge board into a "Slot-load" machine if we can get that controller working in the first place.
Interesting idea.
I was digging around on this, I couldn't find anything on the Sonnet ATA Raid 100 on their site, but I did find the ATA Raid 133 and it was supported as a bootable device in OS 9.  So their may be hope yet on both of those.
Even better idea :)

We have to face a several issues, find the firmware with Mac os 9 drivers compatible with this ATA133 bridge board  and know how to install them inside the board  (I guess we have to reflash an EPROM or something similar)

Sonnet has a firmware update for the ATA 133 Raid.  I am considering trying to flash that one, hoping that it will fix the firmware properties.

The firmware properties seem to be the only issue so that it can be initialized properly.  Once booted I'm pretty sure drivers won't be an issue.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 22, 2016, 10:03:04 AM
  As I mentioned, the Sonnet Tempo RAID ATA133 doesn't use a Promise chipset.  It's a completely different foundation.  Just to confuse the issue, the Sonnet Tempo ATA133 (non-RAID) did use a Promise chip but not the same as the one in either revision of the Xserve.  The boot code block within the firmware is probably the same between the RAID and non-RAID chips however.  This might mean 'grafting' that block of code into the another firmware file and possibly recalculating the checksum.  This isn't my area of expertise but I'm sure there is someone out there with experience editing video card ROMs who could help.

  You are most likely right that the firmware is probably the only issue, not drivers.  The only thing I'm unsure of is how this plays along with the fact there are actually two Promise controllers in the Xserve, one on top of and one on the bottom of the bridge board.  It may not matter at all or it might mean only one can be enabled at any time.  We will see.

  It shouldn't affect OS X support after the change, but I'd like to get a spare bridge board to experiment with so I don't permanently screw my current one.  If it somehow creates a situation where OS X doesn't like it any more then at least I would have the option of swapping bridge boards at any time.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: DieHard on June 22, 2016, 04:35:27 PM
Found some cards in the storage room...

I have a Promise Ultra100 PCI, PDC20267.

Probably PC only, can you flash it mac ?

Yours if you want it...
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 22, 2016, 09:07:20 PM
  I imagine either the Mac flasher has to be tricked into accepting the PC card as a valid destination, or, if we can extract the Mac ROM from Sonnet's flasher, flashed on a PC using the Mac ROM.  Having another close Promise 'family member' probably wouldn't hurt.  The only thing I'm not sure of is if it's better to go to me or to nanopico.  I guess I'll ask him.

  Meanwhile, I found a firmware/ROM flash program for the Sonnet Tempo RAID ATA100 in an archive DVD disc I have.  Not sure why I ever saved this program two years ago, seeing as I never owned one of these cards, but it may very well be what we need to make the Xserve work.  (I must have been psychic!)  I'd like to post it in the downloads so nanopico can get his hands on it (and for anyone elses' benefit).  How might I go about uploading it?

  The parallel ATA conversion adapters for the optical drive bus arrived in the mail yesterday.  They have a generic sticker on them that says "SATA" but they most definitely are PATA-to-PATA.  I'm now booting the Xserve from the SSD in this carrier instead of the external firewire.  No issues and slightly faster of course.  The only thing I don't get any more is an activity LED, but I could use one of the menu bar drive light utilities I have on all my other OS 9-and-earlier machines.

(http://i1262.photobucket.com/albums/ii607/SpawnedFromTheEther/CAM00396.jpg)
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 22, 2016, 09:45:04 PM
I was just digging around in storage here and found the following Promise PC-ROM cards from the same generations as the Mac ones:

- Ultra100 ATA (PDC20267) - physically modified and flashed to work as FastTrack100 RAID
- FastTrak100 RAID (PDC20267)
- Ultra100 TX2 ATA (PDC20268)
- Ultra133 TX2 ATA (PDC20269)

  I thought I had a FastTrak133 RAID somewhere but I can't find it right now.  Anyway, it seems I'm good for Promise cards, but see if nanopico want the one you have.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 23, 2016, 07:57:39 AM
I was digging around looking at how to flash these cards from PC to Mac.

I'm not sure I fully understand the process correctly, but it seems to involve moving chips around between various cards and such, and I'm just not sure that's something I want to tackle.

On the plus side, (excuse the babbling, I'm just thinking out loud here) I have some add on cards for sata in other machines.  Even though they are not the same, they are setup in the same manner in open firmware (directly on the pci bus) and bootable to 9 only they report as SCSI devices (as is well known).
The big thing with these is that it reports the chip as the compatible flag and contains the OS 9 firmware driver on the card.

The initialization issue is related to interrupt initialization.  So a Promise raid controller for Mac (even if not the same one) would at least probably point out the things we are missing in firmware besides the driver side of it.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 23, 2016, 08:59:14 AM
  Agreed, there should be some common code in the various OS 9 bootable ROMs/firmware images.  If it becomes necessary I have the equipment and skills to do chip exchanges, but there most likely are other ways to deal with this in software/firmware only.  Further, we definitely want to try to keep these changes within the skill level of the average user so we maximize the value of our effort.

  That said, I'm prepared to do soldering if it helps with proof of functionality.  I'll wait and see where we get with the flashing aspect first though.  It shouldn't be that big a deal to flash an existing Mac chip with another Mac ROM.

  I had a thought yesterday that maybe someone more familiar with Apple's development timeline could answer.  The MDD motherboard had all the landing points for firewire 400 & 800 ports and ICs.  The OS 9 bootable version simply omitted the FW800 parts.  The first Xserve has all the landing points for FW800 components but they were omitted.  Given what we know already about what all now works when booting 9 on the Xserve, is it possible that in early development Apple actually considered making OS 9 support official but then later rigged it to fail?  This seems quite plausible.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 23, 2016, 09:56:13 AM
  I had a thought yesterday that maybe someone more familiar with Apple's development timeline could answer.  The MDD motherboard had all the landing points for firewire 400 & 800 ports and ICs.  The OS 9 bootable version simply omitted the FW800 parts.  The first Xserve has all the landing points for FW800 components but they were omitted.  Given what we know already about what all now works when booting 9 on the Xserve, is it possible that in early development Apple actually considered making OS 9 support official but then later rigged it to fail?  This seems quite plausible.

Considering these machines came out during the OS X time frame I don't think they gave any thought to enabling FW800 to OS 9.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 23, 2016, 10:03:02 AM
There's a thread from 2014 on this forum that was discussing this issue in regards to the PCI cards:

http://macos9lives.com/smforum/index.php/topic,1926.0.html (http://macos9lives.com/smforum/index.php/topic,1926.0.html)

  One thing I took note of in the dialog window that comes up when starting the Sonnet firmware flasher is they say their product was actually based on FirmTek's cards that were themselves Promise-based.  (In the case of the ATA100 RAID, from the "FirmTek UltraTek/100T2".)  So it was actually FirmTek that wrote the OS 9 compatible firmware for the Promise chips, I guess.  I have to look into it further but it appears FirmTek made Promise-based OS 9 bootable cards in 33, 66, 100 and 133MHz variants.  So it seems we might have another avenue afterall both for ROMs and flashing programs and also for the 133MHz.  I will have to try to confirm if all of these were Promise-based.  FirmTek says on their website that they only produced these cards on a OEM basis for other companies and don't provide any direct support or downloads for them.  So the big question is, was the FirmTek UltraTek/133 Promise-based and what brand were they sold under as a Mac product?

  In a weird twist there was a quote from an article in that thread saying FirmTek was partly founded by former Apple employees.  In the end we may just be finishing Apple's work, in a sense.  I like irony.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 23, 2016, 10:16:45 AM
  I had a thought yesterday that maybe someone more familiar with Apple's development timeline could answer.  The MDD motherboard had all the landing points for firewire 400 & 800 ports and ICs.  The OS 9 bootable version simply omitted the FW800 parts.  The first Xserve has all the landing points for FW800 components but they were omitted.  Given what we know already about what all now works when booting 9 on the Xserve, is it possible that in early development Apple actually considered making OS 9 support official but then later rigged it to fail?  This seems quite plausible.

Considering these machines came out during the OS X time frame I don't think they gave any thought to enabling FW800 to OS 9.

  That's not what I was suggesting - rather the opposite.  What I meant was the intentional omission of FW800 parts from the board, even though all the landing points and tracings were in place to allow for it, may have meant that the FW400-only version of the board was intentionally made that way if Apple were initially considering official OS 9 support for the Xserve, then subsequently the OS 9 support was dropped before the public release.  I really don't see any other reason why they would make all the spots for it in the production board and then leave it out.  In the later MDD they did exactly the same thing but did make OS 9 support official in one of the late motherboard revisions after substantial commercial customer outcry.  It just seems like too much of a coincidence not to consider a similar story with the Xserve.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 23, 2016, 10:36:45 AM
  I had a thought yesterday that maybe someone more familiar with Apple's development timeline could answer.  The MDD motherboard had all the landing points for firewire 400 & 800 ports and ICs.  The OS 9 bootable version simply omitted the FW800 parts.  The first Xserve has all the landing points for FW800 components but they were omitted.  Given what we know already about what all now works when booting 9 on the Xserve, is it possible that in early development Apple actually considered making OS 9 support official but then later rigged it to fail?  This seems quite plausible.

Considering these machines came out during the OS X time frame I don't think they gave any thought to enabling FW800 to OS 9.

  That's not what I was suggesting - rather the opposite.  What I meant was the intentional omission of FW800 parts from the board, even though all the landing points and tracings were in place to allow for it, may have meant that the FW400-only version of the board was intentionally made that way if Apple were initially considering official OS 9 support for the Xserve, then subsequently the OS 9 support was dropped before the public release.  I really don't see any other reason why they would make all the spots for it in the production board and then leave it out.  In the later MDD they did exactly the same thing but did make OS 9 support official in one of the late motherboard revisions after substantial commercial customer outcry.  It just seems like too much of a coincidence not to consider a similar story with the Xserve.

Makes much more sense now. Sorry I got it backwards.  I wonder if it was a mater of OS X didn't support FW800 yet when the machine was released but it was planed so they left the spots on the board to ease manufacturing when OS X supported it? 
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 23, 2016, 01:36:55 PM
  We may never know for sure, but it makes for a good story, right? ;)  But in a truly serious sense, there had to be early development that preceeded the across-the-board OS X-only directive.  If anyone can suggest a better reason for the lack of FW800 but spaces for it, I'd be curious to hear it.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: GaryN on June 23, 2016, 03:43:32 PM
FWIW: I know absolute nothing first, second or even third-hand about what actually went on at Apple then, but having once been in charge of developing and manufacturing an electronic product, I do know the following:

Apple is unusual, almost unique in that the company produces both software and the hardware it runs on. In a situation like that, development proceeds along parallel lines in various divisions based on general "orders from above". SO…

1) Execs poll R&D for new latest and greatest
2) Consult Marketing as to best ideas
3) Decide what to do and issue impossible-to-meet target dates
4) Scramble like chickens to pull the thousand different pieces of the puzzle together and actually have a new product to deliver.

Now when this all gets wound up and moving along, a thousand or so factors come into play: design errors, parts availabilities, Chinese supplier political issues, competitors product announcements, sudden new info from corporate espionage, unexpected failures/issues during testing and on and on.

In the FW aspect, if I'm an engineering manager in charge of laying out the board and they tell me "Don't worry, FW800 won't happen until the next model", if I'm smart, I know that the only certainty in the biz is that nothing will go as planned - therefore, if I can, I allow for FW800 if at all possible without compromising my timeline. That way, if things change, when things change, instead of having to tell Execs "Sorry, there's no more room for that, you said it wasn't needed" and having to look for a new job shortly afterward, I can just be the hero who saw the future and said, "sure, no problem…we not only left room for that, but it's already in the layout, just in case…What? a bonus? Oh really, I was just doing my job after all, but thank you.".

Or maybe, the supplier who swore they could deliver the FW800 chip on time didn't - simple as that.

These are obviously only two of a hundred possible scenarios, but you get the idea, I'm sure.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 23, 2016, 06:26:40 PM
FWIW: I know absolute nothing first, second or even third-hand about what actually went on at Apple then, but having once been in charge of developing and manufacturing an electronic product, I do know the following:

Apple is unusual, almost unique in that the company produces both software and the hardware it runs on. In a situation like that, development proceeds along parallel lines in various divisions based on general "orders from above". SO…

1) Execs poll R&D for new latest and greatest
2) Consult Marketing as to best ideas
3) Decide what to do and issue impossible-to-meet target dates
4) Scramble like chickens to pull the thousand different pieces of the puzzle together and actually have a new product to deliver.

Now when this all gets wound up and moving along, a thousand or so factors come into play: design errors, parts availabilities, Chinese supplier political issues, competitors product announcements, sudden new info from corporate espionage, unexpected failures/issues during testing and on and on.

In the FW aspect, if I'm an engineering manager in charge of laying out the board and they tell me "Don't worry, FW800 won't happen until the next model", if I'm smart, I know that the only certainty in the biz is that nothing will go as planned - therefore, if I can, I allow for FW800 if at all possible without compromising my timeline. That way, if things change, when things change, instead of having to tell Execs "Sorry, there's no more room for that, you said it wasn't needed" and having to look for a new job shortly afterward, I can just be the hero who saw the future and said, "sure, no problem…we not only left room for that, but it's already in the layout, just in case…What? a bonus? Oh really, I was just doing my job after all, but thank you.".

Or maybe, the supplier who swore they could deliver the FW800 chip on time didn't - simple as that.

These are obviously only two of a hundred possible scenarios, but you get the idea, I'm sure.

Sounds like my normal day with my customers, and having to foresee what they want in their software before they even ask me to develop it.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 24, 2016, 10:00:00 PM
  I have to make a correction to something I said earlier.  After extensive digging around and quadruple-fact-checking I've determined that some of the information I got about the Sonnet RAID cards was bad.  There never was a Sonnet Tempo RAID ATA/100, it was only that some people had confused the use of software RAID drives on the Sonnet Tempo ATA/100 with actual hardware RAID.  The firmware flasher I had was also mislabeled - it is for non-RAID ATA/100.

  The implication of this is Sonnet never had a Promise-based ATA/100 or/133 RAID card, so there was no direct crossover into the chipsets used in the Xserve.  FirmTek apparently made such hardware for other brands but not necessarily with Mac compatibility.  (I still have to determine if OWC was one such client of FirmTek for Mac-supported Promise ATA/100 and/or 133 RAID controllers.  Information is scarce.)

  Now this isn't automatically a show-stopper because there is probably a section of the non-RAID firmware that could be patched into the RAID firmware to make OS 9 happy, even though the Promise chips are different part numbers.  What it does mean is that the Xserve controllers probably have to be flashed while attached to a PCI card in a PC.  Not easy but not impossible.  Either that or the Sonnet firmware flasher might be tricked into accepting the Xserve hardware as a valid destination device.

  There's also a possibility of porting the OS X Promise driver back into OS 9 if that is the issue.  Validating that approach would probably involve comparing the driver contents for the non-RAID Promise cards between where they are kept in X and in 9.

  I'll do what I can to continue with this research.  What we need at this point is a way to dump the existing firmware from the Promise chips in the Xserve so the image can be compared to the firmware for the Sonnet Tempo ATA/100.

  Sorry for any confusion caused.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 25, 2016, 01:15:59 PM
  I have to make a correction to something I said earlier.  After extensive digging around and quadruple-fact-checking I've determined that some of the information I got about the Sonnet RAID cards was bad.  There never was a Sonnet Tempo RAID ATA/100, it was only that some people had confused the use of software RAID drives on the Sonnet Tempo ATA/100 with actual hardware RAID.  The firmware flasher I had was also mislabeled - it is for non-RAID ATA/100.

  The implication of this is Sonnet never had a Promise-based ATA/100 or/133 RAID card, so there was no direct crossover into the chipsets used in the Xserve.  FirmTek apparently made such hardware for other brands but not necessarily with Mac compatibility.  (I still have to determine if OWC was one such client of FirmTek for Mac-supported Promise ATA/100 and/or 133 RAID controllers.  Information is scarce.)

  Now this isn't automatically a show-stopper because there is probably a section of the non-RAID firmware that could be patched into the RAID firmware to make OS 9 happy, even though the Promise chips are different part numbers.  What it does mean is that the Xserve controllers probably have to be flashed while attached to a PCI card in a PC.  Not easy but not impossible.  Either that or the Sonnet firmware flasher might be tricked into accepting the Xserve hardware as a valid destination device.

  There's also a possibility of porting the OS X Promise driver back into OS 9 if that is the issue.  Validating that approach would probably involve comparing the driver contents for the non-RAID Promise cards between where they are kept in X and in 9.

  I'll do what I can to continue with this research.  What we need at this point is a way to dump the existing firmware from the Promise chips in the Xserve so the image can be compared to the firmware for the Sonnet Tempo ATA/100.

  Sorry for any confusion caused.

Hey no big deal.  I've back tracked on a lot of what I found and assumed as I learned more.  This is part of research and this is a good thing you found this out so we don't go too far down the rabbit hole.   
I should be getting a Tempo ATA/133 here pretty soon so we'll see.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on June 25, 2016, 03:22:58 PM
  I believe that card is based on an Acard chipset.  I imagine the boot ROM section of the firmware would have to be nearly identical though.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: IIO on June 25, 2016, 07:25:55 PM
hopefully ethernet based copy protection will work. :)

btw, in around march i almost bought a palette with late 2008 Xserve quad-2,66, barebone, 40 servers for USD 3000 from the US.

with shipping and toll and insurance they would have costed me around 130 euros per piece, which is half of what you have to pay here normally.

but 40 was a bit too much, i didnt want to risk to be left with them.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on June 29, 2016, 08:52:30 AM
I love ebay (my wallet doesn't always though).
I did win the auction for the Sonnet ATA card. Should be here in a couple of weeks. (Damn them oceans slowing down deliveries.)
So hopefully it helps to identify some options for getting the xserve completely running.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on July 05, 2016, 09:54:52 AM
Small hint at the possibilities here.
So early boot hate's this ATA controller.  Primarily it has issues initializing it due to cascading interrupts.
There are some properties that set the interrupt controller stuff on the device.
OS 9 just takes that data for what it is and uses it to do the initialization.  So if the values are specifically changed to non-valid values without manipulation then it will be a no-go and cause errors.
Now when OS X boots it knows about this ATA controller and knows that it needs to take these values and change them to something else before it initializes the devices.
Now the errors seen were in the ATA-6 Device and not on the actual root controller.
So the best source of getting this working is likely the driver code from OS X.
So that's where I started and I found something kind of interesting.

In the child devices (not the root ones) there are two variables that correspond to the two child devices below the root controller.
Each one is used for initializing interrupts.
And now the best part.
These are masks. They are set with the following comment.
Code: [Select]
// initialize the interrupt control bits to mask propogation
After they are set the function to registerInterrupts is called.
This goes to the hardware and setups up the interrupts much like the OS 9's code only in this case it knows more about the device.
So now I just have to dig a little deeper and find where all these mask values come from and I should be able to manual change values to either get the thing working or at least move on to another error to resolve.



Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on July 05, 2016, 08:54:33 PM
  It certainly would be nice if we didn't have to mess with the Promise firmware, rather only altering the basic handling by the operating system itself in the Mac OS ROM file or similar.  Whether or not we end up with a bootable device through this route remains to be seen, but we might get it working enough to test the reliability of reads/writes, general system stability, and visibility to the stock disk utility.  If that's successful we can work on bootable firmware after.

  I've been able to confirm that the FirmTek UltraTek/66 was sold by VST.  It was possible to physically modify and flash a PC Promise 66 card with the Mac firmware.  So far I can't sort out exactly where the 'family' went after that.  Supposedly the UltraTek rights were sold to Sonnet who then made the non-RAID ATA/100 card.  I've seen a few spot mentions of later "UltraTek"-marked cards but I don't have any further leads on who would have been selling them and under what brand name.

  What I did find was a possible lead to a person who might (understatement!) know more about these products.  Take a look at the following link:

http://www.beyond.com/766B5949-FB14-420A-BB8C-BD63A36816AC (http://www.beyond.com/766B5949-FB14-420A-BB8C-BD63A36816AC)

  The relevant sections in his work experience are as follows:

"Driver supports MacOS-X on both Intel
Multipliers // May '06 - Jan '14

Multipliers.  Driver supports MacOS-X on both Intel x86 and Power PC processor environments.  Product is shipping since May 2006.  Full Port Multiplier support and bootability since October 2006.  Applied for patent regarding proper implementation of drive hot-swap in RAID environment.  The implementation of the drive hot-swap in shipping drivers is based on the ideas disclosed in this patent application.

Developed the UltraTek/66, Tempo/100, Tempo/133 PCI card (ATA), SeriTek/1Sxxx SATA (Serial ATA), SeriTek/1Vxxx firmware and device driver families for Macintosh, OpenFirmware (OpenBoot) bootstrap driver, Apple PCI DDK for Mac OS-9 (SIM, SCSI Interface Module), Mac OS-X IOKit kernel-driver.  The products are currently selling under either FirmTek or Sonnet brand.  Programming environment: Metrowerks "C" for Mac OS 9, Apple PCI DDK 2.0, Apple's standard C/C++/ObjC tools or MacOS-X.  Usage of I/O Kit framework under MacOS-X.  Cocoa framework for application (firmware flash utility) support.  Hardware tools used: Innotec ATA bus analyser, Bus Doctor SATA/SAS analyzers."


"Driver Architect for MacOS-X IOKit
FirmTek, LLC // Jul '99 - Nov '12"

Driver Architect for MacOS-X IOKit platform, www.firmtek.com.  Developed the Serial ATA firmware and device driver for Macintosh (Mac OS-X 10.4.0 and up, x86 and PPC) based on AHCI 1.3 SATA API model supporting SATA Port Multiplier at FIS-based switching level.  To support S.M.A.R.T. functionality the driver is based on IOATAController, not on the IOSCSIParallelInterface class.  Developed the Serial ATA firware and device driver for Macintosh (Mac OS-X, Mac OS-9) based on Silicon Image 3132/3124 FIS-based SATA API model.  Industry's unique OpenFirmware (OpenBoot) bootstrap driver supporting booting from any drive attached to SATA Port Multiplier.  Driver and pre-boot firmware fully supports SATA Port."


  Literally this guy developed the firmware and drivers for all the cards we've been talking about.  If anyone's going to know what we need to do it's probably him.  He's even worked extensively for Apple.  You might want to read all the detail sections of his resume because he's got extensive knowledge of drivers, including graphics drivers, and boot code on Mac systems going back to the early 90's.

  He must know plenty that he's not bound by non-disclosure agreements to not talk about.  He seems to have a passion for this stuff and would probably be quite pleased we cared about his work.  I have no idea how we might contact him but hopefully someone else on the forums can help track him down.

  I believe this is his LinkedIn profile also:

https://www.linkedin.com/in/george-rath-6117a565 (https://www.linkedin.com/in/george-rath-6117a565)
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on July 06, 2016, 06:43:54 AM
  It certainly would be nice if we didn't have to mess with the Promise firmware, rather only altering the basic handling by the operating system itself in the Mac OS ROM file or similar.  Whether or not we end up with a bootable device through this route remains to be seen, but we might get it working enough to test the reliability of reads/writes, general system stability, and visibility to the stock disk utility.  If that's successful we can work on bootable firmware after.

  I've been able to confirm that the FirmTek UltraTek/66 was sold by VST.  It was possible to physically modify and flash a PC Promise 66 card with the Mac firmware.  So far I can't sort out exactly where the 'family' went after that.  Supposedly the UltraTek rights were sold to Sonnet who then made the non-RAID ATA/100 card.  I've seen a few spot mentions of later "UltraTek"-marked cards but I don't have any further leads on who would have been selling them and under what brand name.

  What I did find was a possible lead to a person who might (understatement!) know more about these products.  Take a look at the following link:

http://www.beyond.com/766B5949-FB14-420A-BB8C-BD63A36816AC (http://www.beyond.com/766B5949-FB14-420A-BB8C-BD63A36816AC)

  The relevant sections in his work experience are as follows:

"Driver supports MacOS-X on both Intel
Multipliers // May '06 - Jan '14

Multipliers.  Driver supports MacOS-X on both Intel x86 and Power PC processor environments.  Product is shipping since May 2006.  Full Port Multiplier support and bootability since October 2006.  Applied for patent regarding proper implementation of drive hot-swap in RAID environment.  The implementation of the drive hot-swap in shipping drivers is based on the ideas disclosed in this patent application.

Developed the UltraTek/66, Tempo/100, Tempo/133 PCI card (ATA), SeriTek/1Sxxx SATA (Serial ATA), SeriTek/1Vxxx firmware and device driver families for Macintosh, OpenFirmware (OpenBoot) bootstrap driver, Apple PCI DDK for Mac OS-9 (SIM, SCSI Interface Module), Mac OS-X IOKit kernel-driver.  The products are currently selling under either FirmTek or Sonnet brand.  Programming environment: Metrowerks "C" for Mac OS 9, Apple PCI DDK 2.0, Apple's standard C/C++/ObjC tools or MacOS-X.  Usage of I/O Kit framework under MacOS-X.  Cocoa framework for application (firmware flash utility) support.  Hardware tools used: Innotec ATA bus analyser, Bus Doctor SATA/SAS analyzers."


"Driver Architect for MacOS-X IOKit
FirmTek, LLC // Jul '99 - Nov '12"

Driver Architect for MacOS-X IOKit platform, www.firmtek.com.  Developed the Serial ATA firmware and device driver for Macintosh (Mac OS-X 10.4.0 and up, x86 and PPC) based on AHCI 1.3 SATA API model supporting SATA Port Multiplier at FIS-based switching level.  To support S.M.A.R.T. functionality the driver is based on IOATAController, not on the IOSCSIParallelInterface class.  Developed the Serial ATA firware and device driver for Macintosh (Mac OS-X, Mac OS-9) based on Silicon Image 3132/3124 FIS-based SATA API model.  Industry's unique OpenFirmware (OpenBoot) bootstrap driver supporting booting from any drive attached to SATA Port Multiplier.  Driver and pre-boot firmware fully supports SATA Port."


  Literally this guy developed the firmware and drivers for all the cards we've been talking about.  If anyone's going to know what we need to do it's probably him.  He's even worked extensively for Apple.  You might want to read all the detail sections of his resume because he's got extensive knowledge of drivers, including graphics drivers, and boot code on Mac systems going back to the early 90's.

  He must know plenty that he's not bound by non-disclosure agreements to not talk about.  He seems to have a passion for this stuff and would probably be quite pleased we cared about his work.  I have no idea how we might contact him but hopefully someone else on the forums can help track him down.

  I believe this is his LinkedIn profile also:

https://www.linkedin.com/in/george-rath-6117a565 (https://www.linkedin.com/in/george-rath-6117a565)

I contacted him via linkedin. We'll see what happens.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on July 13, 2016, 08:55:21 AM
  I believe that card is based on an Acard chipset.  I imagine the boot ROM section of the firmware would have to be nearly identical though.
Just got the card now.

The tempo ATA 133 uses the Promise PDC20269  Not exactly the same as the xserve, but at least the same manufacturer.
I actually have some free time the next few days, so I will be working on this.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacTron on July 13, 2016, 09:42:40 AM
I actually have some free time the next few days, so I will be working on this.

We stay tuned ...  ;D
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on July 13, 2016, 11:01:04 PM
  I believe that card is based on an Acard chipset.  I imagine the boot ROM section of the firmware would have to be nearly identical though.
Just got the card now.

The tempo ATA 133 uses the Promise PDC20269  Not exactly the same as the xserve, but at least the same manufacturer.
I actually have some free time the next few days, so I will be working on this.

  Hmmm, weird.  Every image I ever saw of one looked nothing like a Promise chip or layout.  Maybe Sonnet had multiple releases of the 133 card, first Promise-based, then Acard-based?  Very interesting.

  I guess the thing I'm most interested in is finding out how similar the ROMs are between the ATA100 and ATA133 cards (PDC20268 vs PDC20269).
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on July 14, 2016, 04:54:46 PM
So here's where I am at.  I haven't spent much time on it yet ( I still have the weekend ahead of me).  The Sonnet appears as a scsi card (as is expected and is noted elsewhere here).  It does contain both OS 9 and OS X drivers in it's ROM.  I've reviewed the other properties in both and on the surface they actually look almost the same.   the drivers on the ROM don't normally effect the boot process at the point we see the error (though I can be wrong there).  So no progress yet, but no attempts at anything done either.

I also have spent some time learning all about the device tree.   Man if that's not a mess of confusion to initially wrap your head around, but now that i understand the relationship between various properties and what the mean (interrupt, interrupt-controller, range,reg, #address-cells, #size-cells, #interrupt-cells, interrupt-parent. etc) I can at least piece together the structures of both cards in the device tree and how they map in and out of the various device and what is missing.  Also taking into account details from the OS X driver.   It's possible it will need an driver loaded during early boot. And although it's not in ROM the trampoline does have the ability to load one from disk.  So all is not lost.  I'm 100% sure that this can be done, just not sure how long it will take and to what extent things need to be done.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on August 01, 2016, 11:17:13 AM
UPDATE UPDATE UPDATE!!!!!!!!!!!!!!!!!!!!!!!!!! (with nothing to show for it)

All on board ATA controllers Apple used have special code in the early boot trampoline code.  Since OS X was around when the Xserve was released code of the KIWI never got added to this early boot code.  If you remove the code for any other supported controller you will get the same glorious crashing.  OS X also has special knowledge of this stuff (already acknowledged this earlier) and so being a newer OS it know's how to handle the KIWI (my name for the controller since it's called AppleKiwi in Open firmware).  This is both good and bad news.
The good news is that I know where to patch.  The bad news is I know where to patch.
We do not have any source code for the trampoline executable.  So I am trying to find some options on how to tackle this.
But do not lose hope.  I'm still working on this one (and other things).
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on August 04, 2016, 07:41:45 PM
Another small tidbit.
First (this is probably already known by some, but for others here you are)
NDRV = For the OS.  Has nothing to do with booting the OS.  Now that's not to say they aren't used early on with the OS start up, but not for booting. (example is graphics drivers.  The machine boots fine with out them, but once the OS is up a bit it switches to using the NDRV drivers.

FCODE Drivers = Needed for the device to participate in boot. This is the troublesome part of the xserve at the moment.

FCODE drivers must be stored in the devices ROM.  NDRV may or may not be in the ROM of the device. If they are they are usually the ones listed with the appl in the name and have like OSX OR OS9 in the name or something.  The FCODE drivers you don't really see exactly.

Now in my last post I noted  the trampoline knows about the ATA controllers Apple used, but it doesn't know about the Kiwi because it was never updated to care about it.  So the combination of knowledge of the ATA controller and the FCODE on the device, the trampoline code can set up the device so that OS 9 is happy to use it for booting and such.

Now comes the fun part. Getting the FCODE driver.    As noted above that driver would be in the expansion ROM of the controller.  So we need to dump that and analyze it and then we will be moving forward.  Now how do we get that FCODE you ask?

http://www.fenestrated.net/~macman/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn2000.html (http://www.fenestrated.net/~macman/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn2000.html)

Here is the Apple tech note outline how to dump the expansion rom from a device.

So now this is all fine and good, but what good is it?  Well to help make more sense of it, it would be better in say C or some other language.  Well again Apple to the rescue. In the open source files for OS X there is the bootx project. (Yes I considered modifying that to boot 9, but it does not do enough hardware initialization so it's kind of useless)  In the bootx project files there is a sub project.  This sub project actually is an FCODE to C tool.  How cool. It looks like you just pass it a ROM image and it gives you C code.  I think that is pretty cool.

Now reality becomes a different beast here so we'll see if this actually works.

The other cool thing is this.
http://www.fenestrated.net/~macman/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn2001.html (http://www.fenestrated.net/~macman/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn2001.html)
Ways to work with forth code from open firmware and being able to read it from the drive and execute it from the drive.  Why is this awesome? Well it give me a new approach to the early boot issues.  The current method of attack is to reverse engineer (disassemble and make sense out of a bunch of assembly. Doable, but a pain) the trampoline code. Or now my new idea.  Do sort of like GRUB does in linux with a 2.5 stage boot loader.
Essentially we can write a program that does just enough to initialize the Kiwi controller enough, load it through the boot script in the ROM image, run it then continue on and execute the trampoline code.   

Alright enough thinking out loud.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on August 09, 2016, 11:12:27 AM
I will start by saying, I'm learning more about hardware implementations then I ever thought I would.
Found documentation on PCI bus bindings as related to Open Firmware.
 
As of this time here is what I believe to be the requirements to make this ATA controller work.
An fcode driver will be required to aid in the early boot process. This might eliminate the need to reverse engineer the trampoline code (so I really hope this is the correct solution).
An ndrv for the OS.  This may or may not actually be needed. It's yet to be determined.

So the problem here is the fcode driver.  This is stored in the expansion ROM of the card. So flashing would be required to make this work, maybe.  I don't feel it's a reasonable solution to require flashing the device to make it work.  Now the way Open Firmware evaluates the FCode driver during it's start up indicates that it may be possible to load the driver from a file and execute it before doing any further booting.  When Open Firmware runs the code, it loads it to ram rather run from the rom image. There's a couple of things that might hang this up though.  So the boot script in the ROM can be modified to check for the controller and if found, load a secondary file from disk with the fcode driver and some instruction on loading and running it. Then when that returns, the original boot code can continue and if that actually works, then we have a working ATA Controller. 

Just a sidenote for anyone interested.  Fcode is nothing more than forth that has been tokenized to byte code that Open Firmware interprets.  It's pretty much exactly how Javascript and .Net work with compiling to byte code.  Thus making the drivers universal and completely independent of architecture.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on August 10, 2016, 08:07:00 PM
  I've been away on vacation for a bit but I thought I'd check in.  Quite fascinating stuff!  You seem to be hinting at the possibility of using some sort of 'kick-start' drive to contain the early-boot fcode driver source file for the kiwi, which I suppose could even be a RAM-disk.  I greatly appreciate the elegance of that work-around.  Hopefully creating such a driver isn't too difficult.

  Once I return home next week I'll be paying close attention again. All very interesting!

P.S. In the spirit of all things vintage, this message was composed on an early-2000's tablet PC using a Wacom pen and Windows XP Tablet Edition's handwriting recognition!  Who needs an iPad anyway...
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on August 16, 2016, 06:12:39 AM
  I've been away on vacation for a bit but I thought I'd check in.  Quite fascinating stuff!  You seem to be hinting at the possibility of using some sort of 'kick-start' drive to contain the early-boot fcode driver source file for the kiwi, which I suppose could even be a RAM-disk.  I greatly appreciate the elegance of that work-around.  Hopefully creating such a driver isn't too difficult.

  Once I return home next week I'll be paying close attention again. All very interesting!

P.S. In the spirit of all things vintage, this message was composed on an early-2000's tablet PC using a Wacom pen and Windows XP Tablet Edition's handwriting recognition!  Who needs an iPad anyway...

The stage I'm thinking of loading, won't require a kick-start disk.  It would still be in the execution context of Open firmware which has the capability of loading from disk so it would be the build in disk.   I was able to boot from the internal drive but it failed during the trampoline like we saw earlier.  This fix would run far before that.

Not sure when I will get on this as my time is kind of limited at the moment, and I have no reasonable setup and space to work.  This will be resolved shortly after some painting is complete in the work area and I set it all up again.
Title: Re: Booting an Xserve G4 into Mac Os 9.
Post by: MacOS Plus on January 30, 2017, 02:57:40 PM
  I have one additional tidbit of information regarding Promise chipsets.  The story goes that due to rampant flashing of cheaper PC cards to Mac ROM in earlier generations, Promise took the step of making crossover impossible on the PDC20268 and PDC20269 non-RAID chips.  They created some sort of customized version denoted by the addition of the letter "M" to the end of the part numbers, by which it was not supposed to be possible to interchange the ROM images.

  Oddly, there doesn't seem to have been a PDC20270M variant, I guess since there was no retail Mac card released.  What this suggests is that the PDC20270 chip in the Xserve should be flash compatible with the PC card chip.  As a last resort, and as I said in an earlier posting, I would be willing to attempt a physical removal/re-solder transfer of a chip from an Xserve board to a PC or Mac PCI card if there is no other means of reading or writing the flash ROM within the Xserve.  Further, all single-chip cards with a 68/68M/69/69M/70 chipset appear to use a virtually identical PCB reference design and identical chip pin count/layout, suggesting any of those cards could host the chip from the Xserve for this purpose.

  Obviously I'm still hoping for a software-based solution. ;)
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: DieHard on January 31, 2017, 08:01:06 AM
Thanks for the update... I really thought you abandoned this in 2017... but you are one tenacious MF and I love you for that :)
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on January 31, 2017, 09:09:00 AM
  I'm hoping to hear more from Nanopico and ELN again this year.  They seem to still be working away at the core issues with the OS.  The machine is still fully usable aside from the Promise ATA device.  Now that I finally have a working PTIII config I'm going to see if it plays nice with that.  One way or another, the 9serve will move on from being a curiosity/toy and do some real work.

  Right now I'm in the process of reorganizing my studio space and all the rest of the computers and parts here.  (Mountains, I tell ya!)  Many of my build projects have finished the major testing phases and will be finalized and put into service this year.  I just got another new desk yesterday to help with the 'space crisis' I'd hit for workstation real estate.  It's going to be a good year.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on January 31, 2017, 11:33:49 AM
  I'm hoping to hear more from Nanopico and ELN again this year.  They seem to still be working away at the core issues with the OS.  The machine is still fully usable aside from the Promise ATA device.  Now that I finally have a working PTIII config I'm going to see if it plays nice with that.  One way or another, the 9serve will move on from being a curiosity/toy and do some real work.

  Right now I'm in the process of reorganizing my studio space and all the rest of the computers and parts here.  (Mountains, I tell ya!)  Many of my build projects have finished the major testing phases and will be finalized and put into service this year.  I just got another new desk yesterday to help with the 'space crisis' I'd hit for workstation real estate.  It's going to be a good year.

Sorry it may be a while before you hear more from us on this one for a couple reasons.
1. It's very time consuming.
2. Between work, school and family (that's between the two of us not just me or ELN) it is hard to work on it for very long at a time
3. I honestly have done nothing on this since probably November since I've been trying to stabilize my mood so I can live a normal life again.  Though I have started working on it again.


We have a lot of work to do on that early trampoline/boot stuff that is hanging it up right now, but we do have a very good idea of what needs to be done, but not exactly how to do it right now. So no fear it will be worked on.
1.5 GB limit right now is our current goal.
Mac Mini and Xserve are probably shortly after that, but I'm not sure yet.
And I still poke around with my G5 to see how far that can get, though I'm a little hesitant right now to poke around too much after bricking my iBook :'(
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on January 31, 2017, 11:38:52 AM
  Finally, just to throw it a challenge, I put the 64-bit LSI fibre channel card this machine originally came with into the remaining slot in the riser (next to the Magma bridge card).  The machine took longer to get through the start-up disk detection, again because it was now scanning the fibre channel bus for a link and drives.  After the long pause it again booted as normal!  System Profiler shows the card present.  I don't know if it would actually communicate with an FC chassis under OS 9 though.  Unfortunately I don't have any other FC gear around any longer to test that with.

Yes I know I'm quoting an old post, but...
I just got one of those cards  for my G4 xserve.  I have an xserve raid (maxed with all 14 slots filled with 750 GB drives).  I'll see if it can boot into 9 from that.  Would be kind of neat.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on February 01, 2017, 06:06:22 AM
  Finally, just to throw it a challenge, I put the 64-bit LSI fibre channel card this machine originally came with into the remaining slot in the riser (next to the Magma bridge card).  The machine took longer to get through the start-up disk detection, again because it was now scanning the fibre channel bus for a link and drives.  After the long pause it again booted as normal!  System Profiler shows the card present.  I don't know if it would actually communicate with an FC chassis under OS 9 though.  Unfortunately I don't have any other FC gear around any longer to test that with.

Yes I know I'm quoting an old post, but...
I just got one of those cards  for my G4 xserve.  I have an xserve raid (maxed with all 14 slots filled with 750 GB drives).  I'll see if it can boot into 9 from that.  Would be kind of neat.

My XServe is not in a place I can turn it on at the moment so I did some tests on a DA and MDD.

So yes as MacOS Plus says the card is recognized by OS 9.  With it installed the boot time was terrible.  I didn't directly time it, but getting it so I could click on anything took close to a minute.

OS X works fine with it and does not hang up booting.  This to be expected.
Connected the XServeRaid and tried again, same long boot in OS 9 and no drive detected. No activity even on the XServeRaid.  Boot OS X and drives in the Raid are all recognized and work as they should.

I have not tried booting from the drive yet.

So conclusion, the card shipped with the XServe is not usable in OS 9, but does work with OS X in a MDD and DA.

If I get a chance this evening I will try booting from it and see if it finds it as a boot device. I suspect it will hang and fail at some point, but will load and start, much like what the internal drive can do.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on February 01, 2017, 08:52:06 AM
  Are you saying the LSI card seems to make the machines run horribly slow?  If so that sounds similar to what happened with my Medianet card on OS 9 versus working properly under OS 8.6.  If so, I wonder if the same sluggishness would persist if the LSI card were in a Sawtooth or earlier model booting 8.6?

  I also had a similar experience with a GeForce 2MX card in a Quicksilver booting OS X the other day.  All I wanted to do was re-flash the ROM, but the system was unusable with it installed even though it would eventually complete a boot.  Different issue but similar result.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: nanopico on February 01, 2017, 09:22:40 AM
  Are you saying the LSI card seems to make the machines run horribly slow?  If so that sounds similar to what happened with my Medianet card on OS 9 versus working properly under OS 8.6.  If so, I wonder if the same sluggishness would persist if the LSI card were in a Sawtooth or earlier model booting 8.6?

  I also had a similar experience with a GeForce 2MX card in a Quicksilver booting OS X the other day.  All I wanted to do was re-flash the ROM, but the system was unusable with it installed even though it would eventually complete a boot.  Different issue but similar result.

The LSI card did not cause any problems in OS X.  Machines appeared to run at the same speed with no issue.  In OS 9 the machines ran just fine once booted, but during boot/startup it seemed hung.  You would see the desktop, and move the mouse (I've seen this in a hung system as the mouse is handled by hardware and won't be broken by a hang), but I could not click on anything and have it do anything. After a little over a minute, it was fine and everything worked with no issue.
During start up I could see the LSI card lights flickering like it was trying to find something, the raid was having nothing to do with and showed no activity at all with it's fibre channel lights.
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: MacOS Plus on April 26, 2017, 11:45:25 AM
  Very minor update - I finally have in transit to me two Sonnet Tempo ATA133 PCI cards (Promise PDC20269M chipset), a spare Xserve G4 Rev.1 ATA bridge board, and a Sonnet MDX Dual 1.8GHz CPU upgrade all destined for one of my G4 Xserves.  (Now I no-longer have to consider ripping the MDX out of my MDD FW800 9.2.2 system.)

  One other thing I really still would like to get hold of though is a couple of the metal CPU airflow baffles from the Rev.2 1.33GHz Xserve G4 CPU modules.  If anyone can help out with that please let me know.  A longer shot would be a front bezel for the Rev.2 Xserve G4 Slot-load since I want to see if it can be fit to the Rev.1 chassis with a substitute slot-load optical drive in place without the need to hack up anything severely.

  More OS9-on-Xserve experiments to come...
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: IIO on July 10, 2017, 09:04:38 AM
i am looking forward for a solution for the mini G4. just got one for 17 euros.
would be great to avoid classic enviroment to run koblo studio. headless if neccessary.
Title: Re: Mac Os 9 booting on: xServe G4 (Detailed Posts)
Post by: macStuff on May 28, 2019, 07:24:18 AM
ive just located the firmware from the VST ultatek/66 card from back in (june 2000)

re: history of the mac bootable ATA/IDE/PCI:
firmtek licensed their firmware to VST technologies first; who sourced the boards from Promise; and then Sonnet; who later switched to Acard rather than promise;

for all you people who have promise cards; please pay attention to the storage tech section of teh site; ive posted a bunch of firmware files there just now
Title: Re: Booting a xServe G4 into Mac Os 9.
Post by: macStuff on June 01, 2019, 05:24:21 PM
So the big question is, was the FirmTek UltraTek/133 Promise-based and what brand were they sold under as a Mac product?

the ultratek/133 is exactly the same as the Sonnet Tempo ATA/133
http://macos9lives.com/smforum/index.php/topic,5024.0.html
which is a PDC20269 chip from promise

i just ordered 1 of each, the 133 + 100 versions
from ebay