[wroteafaq]

I have an assortment of drives here:

3301s that I burned SGI firmware (512 byte/block) for back in the day - it was in a socketed OTP 27C256 SOIC (IIrc), so no big deal.
I think I just copied the EPROM from an SGI-supplied drive to a few non-SGI ones.

3401s and 3501s, all from SGI, so also with the appropriate firmware.

As I'm starting to mess around again (with Indigo/2/Indy-era machines), I'd like to back up the firmware in the latter drives.  To that
end I just popped the lid off of the 3501 and found that it's now in a soldered-down flash part, which makes sense.  I haven't looked
into the 3401s yet, so I don't know which it is.

My question is this:  Where does one find the necessary utilities (presumably DOS, maybe windoze) for reading/writing that flash?

[weblacky]

This is the first I've heard of someone being able to do this, perhaps you could explain more?

I don't know much about flashing but I do know you need to look up support for flashers you find. Sometimes the entire family line is stated, sometimes individual chips (depends). If I were you I'd just lookup the most popular hobby flashers today, then lookup the program support and see if your chip families are on their. They don't make it a secret but you MIGHT have to download the flasher and look through its support list of CHIPs to read and such...

[robespierre]

The information from the Texas A&M University SGI Hardware FAQ is that only one model of Toshiba CD-ROM drive had "special" firmware and that it was soon made unnecessary by changes to the IRIS 4D boot code.

4D20, 25, 70, 80 and 85s and most Power Series machines can boot only
from SGI CD-ROMs or later Toshiba 3401s which have SGI firmware
activated by the modification described below. (Newer Toshiba models
don't have that firmware and won't work.) Older SGIs can boot only
from a local tape drive or over the network. Newer machines (4D30 and
35s, Indigos, Challenges, Onyxes, Indys, Indigo^2 etc.) have smarter
PROMs and can boot from at least some third-party CD-ROMs, for example
the Sony and Toshiba drives intended for Suns.

Dave Olson of SGI says, The basic requirement for
Indigos is that the drive be set to use a 512 byte block size. Since
Indigos don't reset the SCSI bus on reboot or halt, you *might* be
able to boot your machine in some other way, set the CD-ROM's
blocksize with a devscsi program while the system is up and then
install from it, but I won't swear to it. Late R4K Indigos, Indys,
Indigo2s, and Onyx/Challenges all know how to set the block size if
the drive identifies itself as a CD-ROM, reports the block size as
something other than 512 bytes in the block descriptor and accepts
the new block size in the block descriptor.

So there are three levels of optical device support depending on the vintage of computer.

1. Oldest (Professional IRIS, Power Series, Personal IRIS 20-25):
No understanding of optical devices in the boot PROM code. To boot from CD-ROM, the drive must start up in 512 byte mode and identify itself as a hard disk.

2. Mid-era (IRIS Indigo R3000, Personal IRIS 30-35):
Knows about the optical device type, but expects 512 byte mode to be enabled by default at boot time. To boot from CD-ROM, the drive must start up in 512 byte mode.

3. Later (Indigo R4000, Indigo2, Indy, Onyx and everything after):
Knows about optical devices and can set 512 byte mode using a MODE SELECT command. The only requirement is that the drive is capable of setting 512 byte mode.

I don't know where the Crimson falls here because the FAQ doesn't mention it specifically. The above categories are for booting from the PROM environment; support within IRIX has more complex requirements involving mediad, digital audio, etc., but at least in later IRIX versions they all generally work.

Each successive level supports a wider selection of optical drives. The drives supported by the first level 1 computers either were sold by SGI with qualified firmware, or are later double-speed Toshibas set with a solder bridge to 'SGI mode'. The level 2 computers can, additionally, use any drive with a '512 byte' jumper set on it. Level 3 can, additionally, use any drive that responds to MODE SELECT commands to set the block size to 512, which is a large array of models and includes some DVD drives.

There's one additional question here that I don't know the answer to, yet. The SCSI protocol provides that some MODE SELECT parameters can be saved, that is, stored in non-volatile memory on the drive and made to be the default for future power-on cycles. It may be that certain drives save the block size when instructed to do so, which would mean that once they have been set up, they would work for booting on Level 2 machines. To my knowledge, no one investigated this during the period and wrote about it, but it would mean that two drives that appear physically identical could act differently in terms of their boot support on an Indigo. There would be drawbacks to such a capability, of course: moving such a drive from a workstation to a PC that expects 2048 byte blocks would generate customer support calls.

Your project to archive SGI-specific firmware is a noble one, but I don't even know if the drives have a device firmware update (DFU) capability. Just because a piece of hardware contains a Flash chip does not mean that it has implemented writing to that chip! In many cases, Flash (especially NOR Flash) was used as a replacement for EPROM firmware storage, which is never in-circuit programmable. Without DFU, there is also no mechanism to save the firmware contents to the host. You would need to desolder the component and put it in an appropriate socket in a device programmer supporting that chip to read it, the same way you need to do with EPROMs.

[jwhat]

Hi robespierre & co,

think that some of CD-ROM/DVD-ROM that SGI supplied may also have had jumper that allow selection of 512 Block Size which was one of "features" that was needed to allow IRIX boot from CD/DVD.

Sorry I can't provide more specific info, but did quick look for the various dead Toshiba DVD-ROMs without any success.

Cheers from Oz,

jwhat/John

[weblacky]

Yes, I have several optical drives from Toshiba, Plextor, Pioneer, etc that have that jumper...oddly modern Irix seems to HATE when I set that jumper! It REALLY WANTS to use the SCSI select mode to change to 512 block mode from a native 2048 block mode via commands. You'd think it'd be cool. I've NEVER gotten any optical drive to boot in 512 mode with the jumper, but they work when it's in 2048 block mode then gets switched.

I don't know...never bothered to care enough to find out...I just have drives that work.

[Jacques]

I have an assortment of drives here:

3301s that I burned SGI firmware (512 byte/block) for back in the day - it was in a socketed OTP 27C256 SOIC (IIrc), so no big deal.
I think I just copied the EPROM from an SGI-supplied drive to a few non-SGI ones.

3401s and 3501s, all from SGI, so also with the appropriate firmware.

As I'm starting to mess around again (with Indigo/2/Indy-era machines), I'd like to back up the firmware in the latter drives.  To that
end I just popped the lid off of the 3501 and found that it's now in a soldered-down flash part, which makes sense.  I haven't looked
into the 3401s yet, so I don't know which it is.

My question is this:  Where does one find the necessary utilities (presumably DOS, maybe windoze) for reading/writing that flash?

The only flash utility I have is for DOS and I used it to flash my SD-M1401 drive to RPC1 to be region free. I’m not sure what other capabilities the flash tool has unfortunately. I can dig it out if you want?

[jan-jaap]

So there are three levels of optical device support depending on the vintage of computer.

1. Oldest (Professional IRIS, Power Series, Personal IRIS 20-25):
No understanding of optical devices in the boot PROM code. To boot from CD-ROM, the drive must start up in 512 byte mode and identify itself as a hard disk.

2. Mid-era (IRIS Indigo R3000, Personal IRIS 30-35):
Knows about the optical device type, but expects 512 byte mode to be enabled by default at boot time. To boot from CD-ROM, the drive must start up in 512 byte mode.

3. Later (Indigo R4000, Indigo2, Indy, Onyx and everything after):
Knows about optical devices and can set 512 byte mode using a MODE SELECT command. The only requirement is that the drive is capable of setting 512 byte mode.

I don't know where the Crimson falls here because the FAQ doesn't mention it specifically.

All correct, but to make it more complicated: the PROM firmware was built from the same source tree as IRIX.

IRIX first supported CDROMs in IRIX 4.0.

Earlier PowerSeries PROM versions were derived from the 3.x codebase, but the last versions were derived from 4.0. With these PROM chips installed, a PowerSeries will recognize a CD-ROM and boot from it. A Crimson always has PROMs from the 4.0 series and does support the CDROM. Same (amazingly) for the Personal IRIS 4D/3x, even though it can run IRIX 3.3 with the use of a special 4D/35 support tape.

PowerSeries PROM firmware is split into CPU firmware (on the IP5/IP7/IP9 CPU card) and IO firmware (on the IO2/IO3/IO3B). You cannot mix and match PROM firmware derived from 3.x and 4.0 in a single system. Really, you should have identical firmware on all CPU boards and matching firmware on the IO board.

NB: For those with PowerSeries systems: I have the latest PROM images.

[wroteafaq]

This is the first I've heard of someone being able to do this, perhaps you could explain more? 

I don't know much about flashing but I do know you need to look up support for flashers you find.  Sometimes the entire family line is stated, sometimes individual chips (depends).  If I were you I'd just lookup the most popular hobby flashers today, then lookup the program support and see if your chip families are on their.  They don't make it a secret but you MIGHT have to download the flasher and look through its support list of CHIPs to read and such...

The first you've heard about which part?  The EPROM copying in the 3301 or being able to flash the firmware in the newer drive?

If the former, as I said, it was trivial, and I'm certain that the quote attributed to Dave Olson is slightly wrong, because that wasn't my experience.  I had an SGI-supplied 3301 that I could boot machines from for IRIX installs (I used to run a lot of 4D and Power Series deskside systems in addition to the Indy/Indigo/2 - and the big 4D/480 and Challenge XL, so we had to do a lot of installs).  When I got my hands on a few external 3301s that were convenient for moving around, they wouldn't boot, so I did the firmware transplant.

If the latter, it doesn't really have anything to do with the flash memory itself; it's all about how it's integrated into the system and thus what is doing the actual device programming i.e. the CDROM's onboard CPU or the external host.  If I'm reading you properly, you're suggesting that some PC flash utility do the device programming directly, I'm certain that's not a valid case here.  How would you wire it up?  I'm fairly confident that there's (for example) no JTAG chain on here to access the part through. My instinct is that there's a specific utility with which one communicates with the drive's CPU (via the SCSI) in order to get it to program the flash part.  So this is well outside of the realm of yer generic dinky hobbyist wire-these-pins-to-your-parallel-port flash programming hack.  (Qualifier:  I'm a hardware engineer with a room full of Data I/O and other device programmers for doing this stuff, which is why doing the 3301 was easy.)

---

Your project to archive SGI-specific firmware is a noble one, but I don't even know if the drives have a device firmware update (DFU) capability. Just because a piece of hardware contains a Flash chip does not mean that it has implemented writing to that chip! In many cases, Flash (especially NOR Flash) was used as a replacement for EPROM firmware storage, which is never in-circuit programmable. Without DFU, there is also no mechanism to save the firmware contents to the host. You would need to desolder the component and put it in an appropriate socket in a device programmer supporting that chip to read it, the same way you need to do with EPROMs.

Trust me, it has nothing to do with nobility and everything to do with practicality.  If I have a copy of that firmware on disk it's easy to reconfigure a drive as necessary.

About the use of FLASH you're partly right.  As the industry transitioned from EPROM to FLASH for code stores (and in the beginning the parts were of comparable size), device programmers were initially used to program the parts, just as with their predecessors.  But that conferred no advantage because it still came with the device handling, labeling, and inventory problems of the EPROMs they were replacing.  So the schemes evolved to allow for ISP of parts that were soldered down blank; initially in bed-of-nails ATE systems, then boundary scan, etc.  Since the part I found in the 3501 wasn't labeled, that suggests that it was programmed after assembly.  What I don't know is whether that was done in a test system or via the SCSI host, hence the question.  If I take a closer look at the PCB I can probably come up with a reasonable guess as to whether it was the former (presence of test pads and all that), but it's certainly reasonable to ask whether there are any known host (as I said, probably PC) utilities for doing this.  (And as I indicated in my other reply, I don't think I need any lessons in SMT rework or socketing a chip into my UniSite.)

And now that you mention it, I do recall some drives of that era having the little solder jumper pads for changing the block size.  I'll have to take a closer look at what I have and see if it jogs any memories.  I got distracted since my original post and haven't yet looked around for a 3401.

[weblacky]

You’re kidding right? If you’re being serious, I’m dropping out now, you’re purposely antagonizing the people responding to your generalized request.

Your first line was literally discussing programming or swapping specific ICs on a PCB…and you come back with not understanding what being referenced? We can only reference what was written above.

You talk about specific chips one moment then start back with why you shouldn’t use JTAG!?!? You don’t mention JTAG, you asked about grabbing chips off a board and dumping their contents and programming those contents back to another chip, we responded to your request with the materials you referenced?!?

So you’re upset I asked you (in earnest) to explain about this specifics of firmware swapping, when I’ve been passively involved in collecting SGIs for over 20 years, and I’ve never run across someone referencing modifying drives for SGIs, so I enquired about the details of your work.

You asked a question and now you’re unhappy with both the answers and your own question.

Sorry, we cannot help you, you clearly know more than we do about a topic that keeps changing. I guess you’ll have to figure out how to JTAG to an unspecified platform, without assistance, instead of doing what you wanted which was burning EEPROMs plucked from boards to modify drives to solve problems which apparently SGIs do not have in the first place.

I’ve certainly upgraded drive firmware through approved vendor means several times (removable media interface or host interface). You’re talking about jumping firmware lines from one production code to another (assuming everything else is equal) by part programming and swapping (not through an approved vendor method). If you’ve already done this before with success, great. Keep doing it with whatever programmer supports the chips your involved with!

I’m out.

[robespierre]

it has nothing to do with nobility and everything to do with practicality.  If I have a copy of that firmware on disk it's easy to reconfigure a drive as necessary.

Given the information I shared above, I can't see what kind of reconfiguration would ever be needed. You said in your initial post you had Indigo2 and Indy era machines, which don't require special drive firmware. At worst, the R3000 Indigo wants a drive with a 512 byte jumper installed (with some possible exceptions that I also discussed).

About the use of FLASH you're partly right.  As the industry transitioned from EPROM to FLASH for code stores (and in the beginning the parts were of comparable size), device programmers were initially used to program the parts, just as with their predecessors.  But that conferred no advantage because it still came with the device handling, labeling, and inventory problems of the EPROMs they were replacing.  So the schemes evolved to allow for ISP of parts that were soldered down blank; initially in bed-of-nails ATE systems, then boundary scan, etc.  Since the part I found in the 3501 wasn't labeled, that suggests that it was programmed after assembly.  What I don't know is whether that was done in a test system or via the SCSI host, hence the question.  If I take a closer look at the PCB I can probably come up with a reasonable guess as to whether it was the former (presence of test pads and all that), but it's certainly reasonable to ask whether there are any known host (as I said, probably PC) utilities for doing this.  (And as I indicated in my other reply, I don't think I need any lessons in SMT rework or socketing a chip into my UniSite.)

As weblacky said, you seem to have the wind up. You "indicated" your experience with electrical engineering in an earlier section of the same reply, so I don't see how anyone besides you could already know that. Now, with your credentials established, I would expect you to know that 8-bit parallel, 1990-era Flash chips did not support JTAG boundary scan. And simply to belabor the point, note that device programmers can be (and usually were) integrated into automatic chip handling systems so as not to require EPROMs or Flash chips to be labeled for manual insertion. The problems are the same: it cannot be assumed that a product like a CD-ROM drive has the ability to write to its firmware, since it certainly would not be practical to perform factory programming through the bus interface. A product could be engineered with DFU for field upgrades, but that is not a certainty, particularly for mature (8 years old in 1992) technologies like CD-ROM that were sold as commodities.

And now that you mention it, I do recall some drives of that era having the little solder jumper pads for changing the block size.  I'll have to take a closer look at what I have and see if it jogs any memories.  I got distracted since my original post and haven't yet looked around for a 3401.

The XM-3401-B and -E revision have two solder bridges that are decoded to enable either: default 2048 byte mode, (non-vendor-specific) 512 byte mode, SGI mode (appears as a fixed magnetic disk type in INQUIRY commands until the first READ command is sent), or Sun/Intergraph mode (similar purpose but different hacks for different vendors). All the units with these revs came from Toshiba with support for booting old SGI and Sun machines. I think I remember these pads on some other Toshiba models also (XM-4101?).