This article is from a FAQ concerning SCO operating systems. While some of the information may be applicable to any OS, or any Unix or Linux OS, it may be specific to SCO Xenix, Open There is lots of Linux, Mac OS X and general Unix info elsewhere on this site: Search this site is the best way to find anything.
There are a lot of different situations possible here - far too many to cover. I'll handle a few; any common additions to this list are certainly welcome.
Upgrading memory - on the hardware side, that's easy; add the memory and run whatever your hardware uses for a setup program. One gotcha here is that many motherboards with L2 cache can only cache up to a certain amount of memory. Check with your motherboard manufacturer. In many cases, you need at least 64 kB of cache per 16 MB of system memory. From the software side, Xenix handles only 16 MB of RAM; different versions of Unix handle different amounts, so check the release notes for your version. The kernel will automatically see the additional memory, but may not put it to optimal use. There are a few kernel parameters which can auto-tune themselves within certain ranges (the best-known is NBUF), but most are fixed at link time. So the short answer is that the system will _use_ the memory, but perhaps not in the way you want it to unless you configure and link a new kernel.
Upgrading the CPU - it should work fine, with one notable exception. Older Unix (and Xenix GT) releases have a timing loop in the ad (Adaptec 154x) driver detection code which will time out on many high-end 486 or higher machines, resulting in the host adapter not being detected. Recent Unix releases have this cured; there is a patch for at least some older Unix versions. See the question on 154x detection in section 3.
Using an EIDE drive - first, some background. Traditional hard drives appear to consist of cylinders, heads, and sectors, and the standard hard drive controller driver in SCO products has traditionally expected standard (MFM, RLL, many ESDI, and ATA) hard drives to appear this way. For ATA drives, this is fine up to about 500 MB, at which point the interface details and the BIOS conspire to cause problems. EIDE gets around this by defining a new addressing mode - LBA (Logical Block Addressing). LBA must be supported by your operating system and/or your BIOS, however, and no SCO product prior to OpenServer Release 5 supported LBA mode out of the box. There is a note in the second section of this FAQ on how you may get an EIDE drive beyond 500 MB to work on 3.2v4.x. Also, LBA support is one of the features of uod429a; check the documentation for this patch.
If you're running OpenServer Release 5, your EIDE hardware should work just fine. If you're running an earlier release of SCO Unix, or any release of SCO Xenix, your EIDE hardware should work as long as it's in CHS mode and NOT in LBA mode.
The other caveat is that since /boot is real-mode code which does its disk access through the BIOS, and since the BIOS can only access up to 1024 cylinders, there are several files and directories which must lie entirely within the first 1024 cylinders in order for you to boot. The easiest way to do this is to keep your entire boot filesystem within the first 1024 cylinders. For fresh OSR5 installations, you have the option of creating separate boot and root filesystems; this is generally a good idea, and means that your root filesystem can be as large as you like (since it's only the boot filesystem which needs to be in the first 1024 cylinders). If you do not select a separate boot filesystem, or if you're running an older version of Unix or Xenix, your entire root filesystem should live within the first 1024 cylinders.
Newer BIOSES no longer have that 1024 cylinder limitation (09/13/2000)
Changing SCSI host adapters - there's a big gotcha here. Different host adapters (even the same one, often, if configured differently) use different logical mappings of the drive, and a drive set up under one host adapter may not be readable under another. Even two versions of the same adapter may have this problem; I've seen problems moving from an Adaptec 154xB to a 154xC, and Adaptec recommends reformatting (!). So it may work ... or it may not. Never ever try this without at least one backup which verifies 100% perfectly ... and see the note earlier in this FAQ about using tar or cpio for your backups before considering either to be a good backup program. There is a note in the Unix-specific part of this FAQ on a possible procedure for such a change.
Using an ATAPI CD-ROM - SCO Xenix doesn't support CD-ROMs. SCO Unix (at least since version 3.2.2) does, but prior to OpenServer Release 5, they had to be SCSI CD-ROMs. While SCSI is generally a wiser choice, support for ATAPI CD-ROMs has been added to OpenServer Release 5. While many IDE CD-ROMs are ATAPI CD-ROMs, not all IDE CD-ROMs follow the ATAPI spec. Only those which do are supported. Note that uod429a adds support for ATAPI CD-ROMs; check the notes for this patch to determine whether it's applicable to your system.
My 2 cents; I've recently upgraded my system (a vanilla EIDE/ATAPI based machine). Before replacing the MB and the CPU, I carefully wrote down the list of PCI devices as recognized by the BIOS before the OS5 boot prompt (my system is equipped with a PCI video and network card and a pretty old ISA sound card); also I checked to make sure they were re-inserted in the same PCI slots of the newly built machine. After powering up the machine, everything worked as expected, apart from the fact that it was WAY faster :-)
Got something to add? Send me email.