Author Topic: Mac Os 9 booting on: xServe G4 (Detailed Posts)  (Read 79636 times)

Online DieHard

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 2368
Re: Booting a xServe G4 into Mac Os 9.
« Reply #20 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

Offline jt

  • Enthusiast Member
  • ***
  • Posts: 27
  • new to the forums
Re: Booting a xServe G4 into Mac Os 9.
« Reply #21 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. ;)

jt - old school vector graphics type - Sound/VidCap n00b.

Offline max1zzz

  • Enthusiast Member
  • ***
  • Posts: 32
  • new to the forums
Re: Booting a xServe G4 into Mac Os 9.
« Reply #22 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

supernova777

  • Guest
Re: Booting a xServe G4 into Mac Os 9.
« Reply #23 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) that supports port multiplier + use an external enclosure /w multiple drives (such as http://www.firmtek.com/seritek/seritek-2eEN4/)

« Last Edit: December 09, 2014, 11:05:29 AM by chrisNova777 »

Offline MacTron

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 2116
  • keep it simple
Re: Booting a xServe G4 into Mac Os 9.
« Reply #24 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" ...
Please don't PM about things that are not private.

Offline Protools5LEGuy

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 2750
Re: Booting a xServe G4 into Mac Os 9.
« Reply #25 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.
Looking for MacOS 9.2.4

Offline MacOS Plus

  • Gold Member
  • *****
  • Posts: 418
  • The 9serve Lives!
Re: Booting a xServe G4 into Mac Os 9.
« Reply #26 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.

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 767
Re: Booting a xServe G4 into Mac Os 9.
« Reply #27 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.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline devils_advisor

  • Platinum Member
  • *****
  • Posts: 752
Re: Booting a xServe G4 into Mac Os 9.
« Reply #28 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

Offline MacOS Plus

  • Gold Member
  • *****
  • Posts: 418
  • The 9serve Lives!
Re: Booting a xServe G4 into Mac Os 9.
« Reply #29 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.
« Last Edit: May 16, 2016, 01:33:53 PM by MacOS Plus »

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 767
Re: Booting a xServe G4 into Mac Os 9.
« Reply #30 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.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline MacOS Plus

  • Gold Member
  • *****
  • Posts: 418
  • The 9serve Lives!
Re: Booting a xServe G4 into Mac Os 9.
« Reply #31 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?

Offline Protools5LEGuy

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 2750
Re: Booting a xServe G4 into Mac Os 9.
« Reply #32 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
Looking for MacOS 9.2.4

Offline ELN

  • Gold Member
  • *****
  • Posts: 295
  • new to the forums
Re: Booting a xServe G4 into Mac Os 9.
« Reply #33 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.

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 767
Re: Booting a xServe G4 into Mac Os 9.
« Reply #34 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.

« Last Edit: May 19, 2016, 03:29:51 PM by nanopico »
If it ain't broke, don't fix it, or break it so you can fix it!

Offline MacOS Plus

  • Gold Member
  • *****
  • Posts: 418
  • The 9serve Lives!
Re: Booting a xServe G4 into Mac Os 9.
« Reply #35 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.

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 767
Re: Booting a xServe G4 into Mac Os 9.
« Reply #36 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.
« Last Edit: May 20, 2016, 04:51:34 AM by nanopico »
If it ain't broke, don't fix it, or break it so you can fix it!

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 767
Re: Booting a xServe G4 into Mac Os 9.
« Reply #37 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.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline MacOS Plus

  • Gold Member
  • *****
  • Posts: 418
  • The 9serve Lives!
Re: Booting a xServe G4 into Mac Os 9.
« Reply #38 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).

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 767
Re: Booting a xServe G4 into Mac Os 9.
« Reply #39 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). 
If it ain't broke, don't fix it, or break it so you can fix it!