Mac Os 9 booting on: xServe G4 (Detailed Posts)

[nanopico]

  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.

[MacTron]

I actually have some free time the next few days, so I will be working on this.

We stay tuned ... 

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

Just got the card now.

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

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

  I guess the thing I'm most interested in is finding out how similar the ROMs are between the ATA100 and ATA133 cards (PDC20268 vs PDC20269).

[nanopico]

So here's where I am at.  I haven't spent much time on it yet ( I still have the weekend ahead of me).  The Sonnet appears as a scsi card (as is expected and is noted elsewhere here).  It does contain both OS 9 and OS X drivers in it's ROM.  I've reviewed the other properties in both and on the surface they actually look almost the same.   the drivers on the ROM don't normally effect the boot process at the point we see the error (though I can be wrong there).  So no progress yet, but no attempts at anything done either.

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

[nanopico]

UPDATE UPDATE UPDATE!!!!!!!!!!!!!!!!!!!!!!!!!! (with nothing to show for it)

All on board ATA controllers Apple used have special code in the early boot trampoline code.  Since OS X was around when the Xserve was released code of the KIWI never got added to this early boot code.  If you remove the code for any other supported controller you will get the same glorious crashing.  OS X also has special knowledge of this stuff (already acknowledged this earlier) and so being a newer OS it know's how to handle the KIWI (my name for the controller since it's called AppleKiwi in Open firmware).  This is both good and bad news.
The good news is that I know where to patch.  The bad news is I know where to patch.
We do not have any source code for the trampoline executable.  So I am trying to find some options on how to tackle this.
But do not lose hope.  I'm still working on this one (and other things).

[nanopico]

Another small tidbit.
First (this is probably already known by some, but for others here you are)
NDRV = For the OS.  Has nothing to do with booting the OS.  Now that's not to say they aren't used early on with the OS start up, but not for booting. (example is graphics drivers.  The machine boots fine with out them, but once the OS is up a bit it switches to using the NDRV drivers.

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

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

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

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

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

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

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

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

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

Alright enough thinking out loud.

[nanopico]

I will start by saying, I'm learning more about hardware implementations then I ever thought I would.
Found documentation on PCI bus bindings as related to Open Firmware.
 
As of this time here is what I believe to be the requirements to make this ATA controller work.
An fcode driver will be required to aid in the early boot process. This might eliminate the need to reverse engineer the trampoline code (so I really hope this is the correct solution).
An ndrv for the OS.  This may or may not actually be needed. It's yet to be determined.

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

Just a sidenote for anyone interested.  Fcode is nothing more than forth that has been tokenized to byte code that Open Firmware interprets.  It's pretty much exactly how Javascript and .Net work with compiling to byte code.  Thus making the drivers universal and completely independent of architecture.

[MacOS Plus]

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

[nanopico]

  I've been away on vacation for a bit but I thought I'd check in.  Quite fascinating stuff!  You seem to be hinting at the possibility of using some sort of 'kick-start' drive to contain the early-boot fcode driver source file for the kiwi, which I suppose could even be a RAM-disk.  I greatly appreciate the elegance of that work-around.  Hopefully creating such a driver isn't too difficult.

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

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

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

Not sure when I will get on this as my time is kind of limited at the moment, and I have no reasonable setup and space to work.  This will be resolved shortly after some painting is complete in the work area and I set it all up again.

[MacOS Plus]

  I have one additional tidbit of information regarding Promise chipsets.  The story goes that due to rampant flashing of cheaper PC cards to Mac ROM in earlier generations, Promise took the step of making crossover impossible on the PDC20268 and PDC20269 non-RAID chips.  They created some sort of customized version denoted by the addition of the letter "M" to the end of the part numbers, by which it was not supposed to be possible to interchange the ROM images.

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

  Obviously I'm still hoping for a software-based solution.

[DieHard]

Thanks for the update... I really thought you abandoned this in 2017... but you are one tenacious MF and I love you for that

[MacOS Plus]

  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.

[nanopico]

  I'm hoping to hear more from Nanopico and ELN again this year.  They seem to still be working away at the core issues with the OS.  The machine is still fully usable aside from the Promise ATA device.  Now that I finally have a working PTIII config I'm going to see if it plays nice with that.  One way or another, the 9serve will move on from being a curiosity/toy and do some real work.

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

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


We have a lot of work to do on that early trampoline/boot stuff that is hanging it up right now, but we do have a very good idea of what needs to be done, but not exactly how to do it right now. So no fear it will be worked on.
1.5 GB limit right now is our current goal.
Mac Mini and Xserve are probably shortly after that, but I'm not sure yet.
And I still poke around with my G5 to see how far that can get, though I'm a little hesitant right now to poke around too much after bricking my iBook

[nanopico]

  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.

[nanopico]

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

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

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

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

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

I have not tried booting from the drive yet.

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

If I get a chance this evening I will try booting from it and see if it finds it as a boot device. I suspect it will hang and fail at some point, but will load and start, much like what the internal drive can do.

[MacOS Plus]

  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.

[nanopico]

  Are you saying the LSI card seems to make the machines run horribly slow?  If so that sounds similar to what happened with my Medianet card on OS 9 versus working properly under OS 8.6.  If so, I wonder if the same sluggishness would persist if the LSI card were in a Sawtooth or earlier model booting 8.6?

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

The LSI card did not cause any problems in OS X.  Machines appeared to run at the same speed with no issue.  In OS 9 the machines ran just fine once booted, but during boot/startup it seemed hung.  You would see the desktop, and move the mouse (I've seen this in a hung system as the mouse is handled by hardware and won't be broken by a hang), but I could not click on anything and have it do anything. After a little over a minute, it was fine and everything worked with no issue.
During start up I could see the LSI card lights flickering like it was trying to find something, the raid was having nothing to do with and showed no activity at all with it's fibre channel lights.

[MacOS Plus]

  Very minor update - I finally have in transit to me two Sonnet Tempo ATA133 PCI cards (Promise PDC20269M chipset), a spare Xserve G4 Rev.1 ATA bridge board, and a Sonnet MDX Dual 1.8GHz CPU upgrade all destined for one of my G4 Xserves.  (Now I no-longer have to consider ripping the MDX out of my MDD FW800 9.2.2 system.)

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

  More OS9-on-Xserve experiments to come...

[IIO]

i am looking forward for a solution for the mini G4. just got one for 17 euros.
would be great to avoid classic enviroment to run koblo studio. headless if neccessary.

[macStuff]

ive just located the firmware from the VST ultatek/66 card from back in (june 2000)

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

for all you people who have promise cards; please pay attention to the storage tech section of teh site; ive posted a bunch of firmware files there just now