Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[DieHard]

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...

[MacOS Plus]

  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.

[MacOS Plus]

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.

[nanopico]

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.

[MacOS Plus]

  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.

[nanopico]

  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.

[MacOS Plus]

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

  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.

[MacOS Plus]

  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.

[nanopico]

  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? 

[MacOS Plus]

  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.

[GaryN]

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.

[nanopico]

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.

[MacOS Plus]

  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.

[nanopico]

  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.

[MacOS Plus]

  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.

[IIO]

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.

[nanopico]

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.

[nanopico]

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.

[MacOS Plus]

  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

  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

[nanopico]

  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

  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

I contacted him via linkedin. We'll see what happens.