summaryrefslogtreecommitdiffstats
path: root/drivers/block/README.ide
diff options
context:
space:
mode:
Diffstat (limited to 'drivers/block/README.ide')
-rw-r--r--drivers/block/README.ide278
1 files changed, 278 insertions, 0 deletions
diff --git a/drivers/block/README.ide b/drivers/block/README.ide
new file mode 100644
index 000000000..39ae4fa79
--- /dev/null
+++ b/drivers/block/README.ide
@@ -0,0 +1,278 @@
+README.ide -- Information regarding ide.c and ide-cd.c (IDE driver in 1.2.x)
+================================================================================
+Supported by: mlord@bnr.ca -- disks, interfaces, probing
+ snyder@fnald0.fnal.gov -- cdroms, ATAPI, audio
+
+(see description later on below for handling BIG IDE drives with >1024 cyls).
+
+Major features of ide.c & ide-cd.c:
+
+ - support for up to two IDE interfaces on one or two IRQs
+ - support for any mix of up to four disk and/or cdrom drives
+ - support for reading IDE ATAPI cdrom drives (NEC,MITSUMI,VERTOS,SONY)
+ - support for audio functions
+ - auto-detection of interfaces, drives, IRQs, and disk geometries
+ -- "single" drives should be jumpered as "master", not "slave"
+ - support for BIOSs which report "more than 16 heads" on disk drives
+ - uses LBA (slightly faster) on disk drives which support it
+ - support for lots of fancy (E)IDE drive functions with hdparm utility
+ - optional (compile time) support for 32-bit VLB data transfers
+ - support for IDE multiple (block) mode (same as hd.c)
+ - support for interrupt unmasking during I/O (better than hd.c)
+ - improved handshaking and error detection/recovery
+ - can co-exist with hd.c to control only the secondary interface
+NEW! - support for reliable operation of buggy CMD-640 interfaces
+ - use kernel command line option: hda=serialize
+NEW! - experimental support for DTC-2278D interfaces
+ - use kernel command line option: hda=dtc2278
+NEW! - run-time selectable 32bit interface support (using hdparm-2.3)
+
+Under construction:
+
+ - improved CMD support: tech info is supposedly "in the mail"
+ - support for interface speed selection on jumperless interfaces
+ - improved detection of non-standard IDE ATAPI cdrom drives
+ - support for non-standard 3rd/4th drive interface on Promise cards
+
+***
+
+IMPORTANT NOTICE: "CMD" EIDE Interfaces will not (by default) work *reliably*
+when drives are attached to the second interface. To "fix" this, supply the
+special kernel "command line" parameter to LILO: hda=serialize
+Failure to do so can cause severe data corruption!
+
+***
+
+To access devices on the second interface, device entries must first be
+created in /dev for them. To create such entries, simply run the included
+shell script: MAKEDEV.ide1
+
+Apparently the early releases of Slackware 2.2 have incorrect entries
+in /dev for hdc* and hdd* -- this can also be corrected by running MAKEDEV.ide1
+
+ide.c automatically probes for the primary and secondary interfaces,
+for the drives/geometries attached to those interfaces, and for the
+IRQ numbers being used by the interfaces (normally IRQ14 & IRQ15).
+
+The primary and secondary interfaces may share a single IRQ if necessary,
+at a slight performance penalty, whether on separate cards or a single VLB card.
+
+Drives are normally found by auto-probing and/or examining the CMOS/BIOS data.
+For really weird situations, the apparent (fdisk) geometry can also be specified
+on the kernel "command line" using LILO. The format of such lines is:
+
+ hdx=cyls,heads,sects,wpcom,irq
+or hdx=cdrom
+
+where hdx can be any of {hda,hdb,hdc,hdd}, or simply hd, for the "next" drive
+in sequence. Only the first three parameters are required (cyls,heads,sects),
+and wpcom is ignored for IDE drives. For example:
+
+ hdc=1050,32,64 hdd=cdrom
+
+If an irq number is given, it will apply to both drives on the same interface,
+either {hda,hdb} or {hdc,hdd}. The results of successful auto-probing may
+override the physical geometry/irq specified, though the "original" geometry
+is retained as the "logical" geometry for partitioning purposes (fdisk).
+
+If the auto-probing during boot time confuses a drive (ie. the drive works
+with hd.c but not with ide.c), then an command line option may be specified
+for each drive for which you'd like the drive to skip the hardware
+probe/identification sequence. For example:
+
+ hdb=noprobe
+or
+ hdc=768,16,32
+ hdc=noprobe
+
+Note that when only one IDE device is attached to an interface,
+it must be jumpered as "single" or "master", *not* "slave".
+Many folks have had "trouble" with cdroms because of this requirement
+of the ATA (IDE) standard.
+
+Courtesy of Scott Snyder, the driver now supports ATAPI cdrom drives
+such as the NEC-260 and the new MITSUMI triple/quad speed drives.
+Such drives will be identified at boot time, as hda,hdb,hdc or hdd,
+just like a harddisk.
+
+If for some reason your cdrom drive is *not* found at boot time, you can force
+the probe to look harder by supplying a kernel command line parameter
+via LILO, such as: hdc=cdrom
+
+For example, a GW2000 system might have a harddrive on the primary
+interface (/dev/hda) and an IDE cdrom drive on the secondary interface
+(/dev/hdc). To mount a CD in the cdrom drive, one would use something like:
+
+ ln -sf /dev/hdc /dev/cdrom
+ mkdir /cd
+ mount /dev/cdrom /cd -t iso9660 -o ro
+
+Please pass on any feedback on the cdrom stuff to the author & maintainer,
+Scott Snyder (snyder@fnald0.fnal.gov).
+
+The kernel is now be able to execute binaries directly off of the cdrom,
+provided it is mounted with the default block size of 1024.
+
+The hdparm.c program for controlling various IDE features is now packaged
+separately. Look for it on popular linux FTP sites.
+
+mlord@bnr.ca
+snyder@fnald0.fnal.gov
+================================================================================
+
+Some Terminology
+----------------
+IDE = Integrated Drive Electronics, meaning that each drive has a built-in
+controller, which is why an "IDE interface card" is not a "controller card".
+
+IDE drives are designed to attach almost directly to the ISA bus of an AT-style
+computer. The typical IDE interface card merely provides I/O port address
+decoding and tri-state buffers, although several newer localbus cards go much
+beyond the basics. When purchasing a localbus IDE interface, avoid cards with
+an onboard BIOS and those which require special drivers. Instead, look for a
+card which uses hardware switches/jumpers to select the interface timing speed,
+to allow much faster data transfers than the original 8Mhz ISA bus allows.
+
+ATA = AT (the old IBM 286 computer) Attachment Interface, a draft American
+National Standard for connecting hard drives to PCs. This is the official
+name for "IDE".
+
+The latest standards define some enhancements, known as the ATA-2 spec,
+which grew out of vendor-specific "Enhanced IDE" (EIDE) implementations.
+
+ATAPI = ATA Packet Interface, a new protocol for controlling the drives,
+similar to SCSI protocols, created at the same time as the ATA2 standard.
+ATAPI is currently used for controlling CDROM and TAPE devices, and will
+likely also soon be used for Floppy drives, removable R/W cartridges,
+and for high capacity hard disk drives.
+
+How To Use *Big* ATA/IDE drives with Linux
+------------------------------------------
+The ATA Interface spec for IDE disk drives allows a total of 28 bits
+(8 bits for sector, 16 bits for cylinder, and 4 bits for head) for addressing
+individual disk sectors of 512 bytes each (in "Linear Block Address" (LBA)
+mode, there is still only a total of 28 bits available in the hardware).
+This "limits" the capacity of an IDE drive to no more than 128GB (Giga-bytes).
+All current day IDE drives are somewhat smaller than this upper limit, and
+within a few years, ATAPI disk drives will raise the limit considerably.
+
+All IDE disk drives "suffer" from a "16-heads" limitation: the hardware has
+only a four bit field for head selection, restricting the number of "physical"
+heads to 16 or less. Since the BIOS usually has a 63 sectors/track limit,
+this means that all IDE drivers larger than 504MB (528Meg) must use a "physical"
+geometry with more than 1024 cylinders.
+
+ (1024cyls * 16heads * 63sects * 512bytes/sector) / (1024 * 1024) == 504MB
+
+(Some BIOSs (and controllers with onboard BIOS) pretend to allow "32" or "64"
+ heads per drive (discussed below), but can only do so by playing games with
+ the real (hidden) geometry, which is always limited to 16 or fewer heads).
+
+This presents two problems to most systems:
+
+ 1. The INT13 interface to the BIOS only allows 10-bits for cylinder
+ addresses, giving a limit of 1024cyls for programs which use it.
+
+ 2. The physical geometry fields of the disk partition table only
+ allow 10-bits for cylinder addresses, giving a similar limit of 1024
+ cyls for operating systems that do not use the "sector count" fields
+ instead of the physical Cyl/Head/Sect (CHS) geometry fields.
+
+Neither of these limitations affects Linux itself, as it (1) does not use the
+BIOS for disk access, and it (2) is clever enough to use the "sector count"
+fields of the partition table instead of the physical CHS geometry fields.
+
+ a) Most folks use LILO to load linux. LILO uses the INT13 interface
+ to the BIOS to load the kernel at boot time. Therefore, LILO can only
+ load linux if the files it needs (usually just the kernel images) are
+ located below the magic 1024 cylinder "boundary" (more on this later).
+
+ b) Many folks also like to have bootable DOS partitions on their
+ drive(s). DOS also uses the INT13 interface to the BIOS, not only
+ for booting, but also for operation after booting. Therefore, DOS
+ can normally only access partitions which are contained entirely below
+ the magic 1024 cylinder "boundary".
+
+There are at least seven commonly used schemes for kludging DOS to work
+around this "limitation". In the long term, the problem is being solved
+by introduction of an alternative BIOS interface that does not have the
+same limitations as the INT13 interface. New versions of DOS are expected
+to detect and use this interface in systems whose BIOS provides it.
+
+But in the present day, alternative solutions are necessary.
+
+The most popular solution in newer systems is to have the BIOS shift bits
+between the cylinder and head number fields. This is activated by entering
+a translated logical geometry into the BIOS/CMOS setup for the drive.
+Thus, if the drive has a geometry of 2100/16/63 (CHS), then the BIOS could
+present a "logical" geometry of 525/64/63 by "shifting" two bits from the
+cylinder number into the head number field for purposes of the partition table,
+CMOS setup, and INT13 interfaces. Linux kernels 1.1.39 and higher detect and
+"handle" this translation automatically, making this a rather painless solution
+for the 1024 cyls problem. If for some reason Linux gets confused (unlikely),
+then use the kernel command line parameters to pass the *logical* geometry,
+as in: hda=525,64,63
+
+If the BIOS does not support this form of drive translation, then several
+options remain, listed below in inverse order of popularity:
+
+ - boot from a floppy disk instead of the hard drive (takes 10 seconds).
+ - use a partition below the 1024 cyl boundary to hold the linux
+ boot files (kernel images and /boot directory), and place the rest
+ of linux anywhere else on the drive. These files can reside in a DOS
+ partition, or in a tailor-made linux boot partition.
+
+If you cannot use drive translation, *and* your BIOS also restricts you to
+entering no more than 1024 cylinders in the geometry field in the CMOS setup,
+then just set it to 1024. As of v3.5 of this driver, Linux automatically
+determines the *real* number of cylinders for fdisk to use, allowing easy
+access to the full disk capacity without having to fiddle around.
+
+Regardless of what you do, all DOS partitions *must* be contained entirely
+within the first 1024 logical cylinders. For a 1Gig WD disk drive, here's
+a good "half and half" partitioning scheme to start with:
+
+ geometry = 2100/16/63
+ /dev/hda1 from cyl 1 to 992 dos
+ /dev/hda2 from cyl 993 to 1023 swap
+ /dev/hda3 from cyl 1024 to 2100 linux
+
+To ensure that LILO can boot linux, the boot files (kernel and /boot/*)
+must reside within the first 1024 cylinders of the drive. If your linux
+root partition is *not* completely within the first 1024 cyls (quite common),
+then you can use LILO to boot linux from files on your DOS partition
+by doing the following after installing slackware (or whatever):
+
+ 0. Boot from the "boot floppy" created during the installation
+ 1. Mount your DOS partition as /dos (and stick it in /etc/fstab)
+ 2. Move your kernel (/vmlinuz) to /dos/vmlinuz with: mv /vmlinuz /dos
+ 3. Edit /etc/lilo.conf to change /vmlinuz to /dos/vmlinuz
+ 4. Move /boot to /dos/boot with: cp -a /boot /dos ; rm -r /boot
+ 5. Create a symlink for LILO to use with: ln -s /dos/boot /boot
+ 6. Re-run LILO with: lilo
+
+ A danger with this approach is that whenever an MS-DOS "defragmentation"
+ program is run (like Norton "speeddisk"), it may move the Linux boot
+ files around, confusing LILO and making the (Linux) system unbootable.
+ Be sure to keep a kernel "boot floppy" at hand for such circumstances.
+
+If you "don't do DOS", then partition as you please, but remember to create
+a small partition to hold the /boot directory (and vmlinuz) as described above
+such that they stay within the first 1024 cylinders.
+
+Note that when creating partitions that span beyond cylinder 1024,
+Linux fdisk will complain about "Partition X has different physical/logical
+endings" and emit messages such as "This is larger than 1024, and may cause
+problems with some software". Ignore them for linux partitions. The "some
+software" refers to DOS, the BIOS, and LILO, as described previously.
+
+Western Digital now ships a "DiskManager 6.03" diskette with all of their big
+hard drives. Burn it! That idiotic piece of garbage isn't even universally
+compatible with DOS, let alone other operating systems like Linux. Eventually
+some kind person will kludge Linux to work with it, but at present the two
+are completely incompatible. If you have this version of DiskManager on your
+hard disk already, it can be exterminated at the expense of all data on the
+drive (back it up elsewhere), by using the "DM" command from the diskette
+as follows: DM /Y-
+
+mlord@bnr.ca