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 ¿?
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
Mactron... I am so interested in the results of this thread.
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?
Looks like a dead end getting OS9 running on these machines.
Yes... CPU will be going into MDD and Xserve will be parted out on eBay and scrapped after iMic and Mactron are satisfied
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?
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
Yeah Elliot and I are working together on this.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.
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.
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.
found a cascading interrupt controller @ 0x00000000
cascadeStack[1] = 58 (ua_size = 2)
DEFAULT CATCH!, code=900 at %SRR0: 00208ca4 %SRR1: 00003030
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.
Just PM'd you, nano. I'll get you that output in the morning.Thank you very much for your help with this.
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.
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.
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).
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 >
One of the USB ports is physically destroyed.
QuoteOne 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
You can now add the xserve to the list of bootable machines.
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.
" /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.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.
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.
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
****************************************************
Imagine the included serial port works for MIDI data.
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
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
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.
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.
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 :)
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)
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.
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.
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.
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.
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.
// initialize the interrupt control bits to mask propogation
After they are set the function to registerInterrupts is called.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 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.
I actually have some free time the next few days, so I will be working on this.
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.
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...
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.
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.
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.
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.
So the big question is, was the FirmTek UltraTek/133 Promise-based and what brand were they sold under as a Mac product?
Howdy All,
First time poster, long time lurker...
I have recently procured an XServe G4 1GHz DP and I'm curious to follow the procedure to boot 9.2.2. I hope you will indulge me a few questions for the professionals here to assist, please!
The Open Firmware commands listed here:
" /pci@F2000000/AppleKiwi@15" find-package drop delete-node
" /pci@F2000000/AppleKiwi@1b" find-package drop delete-node
boot cd:,\\:tbxi
are they required for each boot?
I want to confirm the steps required please:
1- start machine with no drive trays loaded, enter Open Firmware- type commands (above)
2- boot from external FW CD (Unsupported G4s 9.2.2 bootable CD from this site)
3- use ASR and install on SSD or other firewire drive/media
4- boot from SSD from then on?
I noticed MacOS Plus installed an SSD in the optical bay with an adapter, is this still working?
Any other news or updates from the past two years? Or has everyone moved back to their happy G4 towers because they play more quietly?
Thanks for any help. This forum is stellar!
Cheers,
ryebot
The Open Firmware commands listed here:
" /pci@F2000000/AppleKiwi@15" find-package drop delete-node
" /pci@F2000000/AppleKiwi@1b" find-package drop delete-node
boot cd:,\\:tbxi
are they required for each boot?