chain module: bugfixing and cosmetics
[profile/ivi/syslinux.git] / doc / memdisk.txt
index 759a7b2..fecf2dc 100644 (file)
@@ -9,7 +9,10 @@ disk and a (very small - 2K typical) chunk of low (DOS) memory for the
 driver itself, then hooking the INT 13h (disk driver) and INT 15h
 (memory query) BIOS interrupts.
 
-To use it, type on the SYSLINUX command line:
+MEMDISK allows for an OS to detect the MEMDISK instance.  (See the
+"Additional technical information" section below.)
+
+To use it, type on the Syslinux command line:
 
 memdisk initrd=diskimg.img
 
@@ -28,25 +31,44 @@ Note the following:
 
 a) The disk image can be uncompressed or compressed with gzip or zip.
 
-b) If the disk image is one of the following sizes, it's assumed to be a
-   floppy image:
-
-     368,640 bytes -  360K floppy
-     737,280 bytes -  720K floppy
-   1,222,800 bytes - 1200K floppy
-   1,474,560 bytes - 1440K floppy
-   1,720,320 bytes - 1680K floppy (common extended format)
-   1,763,328 bytes - 1722K floppy (common extended format)
-   2,949,120 bytes - 2880K floppy
-   3,932,160 bytes - 3840K floppy (extended format)
-
-   For any other size, the image is assumed to be a hard disk image,
-   and should typically have an MBR and a partition table.  It may
-   optionally have a DOSEMU geometry header; in which case the header
-   is used to determine the C/H/S geometry of the disk.  Otherwise,
-   the geometry is determined by examining the partition table, so the
-   entire image should be partitioned for proper operation (it may be
-   divided between multiple partitions, however.)
+b) If the disk image is less than 4,194,304 bytes (4096K, 4 MB) it is
+   assumed to be a floppy image and MEMDISK will try to guess its
+   geometry based on the size of the file.  MEMDISK recognizes all the
+   standard floppy sizes as well as common extended formats:
+
+     163,840 bytes  (160K) c=40 h=1 s=8                5.25" SSSD
+     184,320 bytes  (180K) c=40 h=1 s=9                5.25" SSSD
+     327,680 bytes  (320K) c=40 h=2 s=8                5.25" DSDD
+     368,640 bytes  (360K) c=40 h=2 s=9                5.25" DSDD
+     655,360 bytes  (640K) c=80 h=2 s=8                3.5"  DSDD
+     737,280 bytes  (720K) c=80 h=2 s=9                3.5"  DSDD
+   1,222,800 bytes (1200K) c=80 h=2 s=15       5.25" DSHD
+   1,474,560 bytes (1440K) c=80 h=2 s=18       3.5"  DSHD
+   1,638,400 bytes (1600K) c=80 h=2 s=20       3.5"  DSHD (extended)
+   1,720,320 bytes (1680K) c=80 h=2 s=21       3.5"  DSHD (extended)
+   1,763,328 bytes (1722K) c=82 h=2 s=21       3.5"  DSHD (extended)
+   1,784,832 bytes (1743K) c=83 h=2 s=21       3.5"  DSHD (extended)
+   1,802,240 bytes (1760K) c=80 h=2 s=22       3.5"  DSHD (extended)
+   1,884,160 bytes (1840K) c=80 h=2 s=23       3.5"  DSHD (extended)
+   1,966,080 bytes (1920K) c=80 h=2 s=24       3.5"  DSHD (extended)
+   2,949,120 bytes (2880K) c=80 h=2 s=36       3.5"  DSED
+   3,194,880 bytes (3120K) c=80 h=2 s=39       3.5"  DSED (extended)
+   3,276,800 bytes (3200K) c=80 h=2 s=40       3.5"  DSED (extended)
+   3,604,480 bytes (3520K) c=80 h=2 s=44       3.5"  DSED (extended)
+   3,932,160 bytes (3840K) c=80 h=2 s=48       3.5"  DSED (extended)
+
+   A small perl script is included in the MEMDISK directory which can
+   determine the geometry that MEMDISK would select for other sizes;
+   in general MEMDISK will correctly detect most physical extended
+   formats used, with 80 cylinders or slightly more.
+
+   If the image is 4 MB or larger, it is assumed to be a hard disk
+   image, and should typically have an MBR and a partition table.  It
+   may optionally have a DOSEMU geometry header; in which case the
+   header is used to determine the C/H/S geometry of the disk.
+   Otherwise, the geometry is determined by examining the partition
+   table, so the entire image should be partitioned for proper
+   operation (it may be divided between multiple partitions, however.)
 
    You can also specify the geometry manually with the following command
    line options:
@@ -56,6 +78,7 @@ b) If the disk image is one of the following sizes, it's assumed to be a
    s=#         Specify number of sectors (max 63)
    floppy[=#]  The image is a floppy image[**]
    harddisk[=#]        The image is a hard disk image[**]
+   iso         The image is an El Torito ISO9660 image (drive 0xE0)
 
    # represents a decimal number.
 
@@ -86,8 +109,12 @@ d) MEMDISK normally uses the BIOS "INT 15h mover" API to access high
    bigraw      Use raw access to protected mode memory, and leave the
                CPU in "big real" mode afterwards.
 
+   int         Use plain INT 15h access to protected memory.  This assumes
+               that anything which hooks INT 15h knows what it is doing.
+
    safeint     Use INT 15h access to protected memory, but invoke
                INT 15h the way it was *before* MEMDISK was loaded.
+               This is the default since version 3.73.
 
 e) MEMDISK by default supports EDD/EBIOS on hard disks, but not on
    floppy disks.  This can be controlled with the options:
@@ -95,15 +122,33 @@ e) MEMDISK by default supports EDD/EBIOS on hard disks, but not on
    edd         Enable EDD/EBIOS
    noedd       Disable EDD/EBIOS
 
+f) The following option can be used to pause to view the messages:
+
+   pause       Wait for a keypress right before booting
+
+g) The following option can be used to set the real-mode stack size.
+   The default is 512 bytes, but if there is a failure it might be
+   interesting to set it to something larger:
+
+   stack=size   Set the stack to "size" bytes
+
+h) Some systems without a floppy drive have been known to have
+   problems with floppy images.  To avoid that those problems, first
+   of all make sure you don't have a floppy drive configured on the
+   BIOS screen.  If there is no option to configure that, or that
+   doesn't work, you can use the option:
+
+   nopass      Hide all real drives of the same type (floppy or hard disk)
+   nopassany    Hide all real drives (floppy and hard disk)
+
 
 Some interesting things to note:
 
 If you're using MEMDISK to boot DOS from a CD-ROM (using ISOLINUX),
 you might find the generic El Torito CD-ROM driver by Gary Tong and
-Bart Lagerweij useful:
-
-       http://www.nu2.nu/eltorito/
-
+Bart Lagerweij useful.  It is now included with the Syslinux
+distribution, in the dosutil directory.  See the file
+dosutil/eltorito.txt for more information.
 
 Similarly, if you're booting DOS over the network using PXELINUX, you
 can use the "keeppxe" option and use the generic PXE (UNDI) NDIS
@@ -142,19 +187,26 @@ http://www.ctyme.com/rbrown.htm, for a detailed description.
 
 The MEMDISK info structure currently contains:
 
-       [ES:DI]         word    Total size of structure (currently 28 bytes)
+       [ES:DI]         word    Total size of structure (currently 30 bytes)
        [ES:DI+2]       byte    MEMDISK minor version
        [ES:DI+3]       byte    MEMDISK major version
        [ES:DI+4]       dword   Pointer to MEMDISK data in high memory
-       [ES:DI+8]       dword   Size of MEMDISK data in 512-byte sectors
+       [ES:DI+8]       dword   Size of MEMDISK data in sectors
        [ES:DI+12]      16:16   Far pointer to command line
        [ES:DI+16]      16:16   Old INT 13h pointer
        [ES:DI+20]      16:16   Old INT 15h pointer
        [ES:DI+24]      word    Amount of DOS memory before MEMDISK loaded
        [ES:DI+26]      byte    Boot loader ID
+       [ES:DI+27]      byte    Sector size as a power of 2
+                               (If zero, assume 512-byte sectors)
+       [ES:DI+28]      word    If nonzero, offset (vs ES) to installed DPT
+                               This pointer+16 contains the original INT 1Eh
+
+Sizes of this structure:
 
-MEMDISK 3.00 and higher has the size of this structure as 27; earlier
-versions had size 26 and did not include the boot loader ID.
+3.71+          30 bytes        Added DPT pointer
+3.00-3.70      27 bytes        Added boot loader ID
+pre-3.00       26 bytes
 
 In addition, the following fields are available at [ES:0]:
 
@@ -166,8 +218,9 @@ this API can be used.
 
 The following code can be used to "disable" MEMDISK.  Note that it
 does not free the handler in DOS memory, and that running this from
-DOS will probably crash your machine (DOS doesn't like drives
-suddenly disappearing from underneath):
+DOS will probably crash your machine (DOS doesn't like drives suddenly
+disappearing from underneath.)  This is also not necessarily the best
+method for this.
 
        mov eax, 454D0800h
        mov ecx, 444D0000h
@@ -200,3 +253,40 @@ suddenly disappearing from underneath):
        mov byte [es:bx], 0EAh  ; FAR JMP
        mov [es:bx+1], eax
        sti
+
+MEMDISK supports the Win9x "safe hook" structure for OS detection.
+(See "Safe Master Boot Record INT 13h Hook Routines," available at
+http://www.osronline.com/ddkx/w98ddk/storage_5l6g.htm as of
+December 7th, 2009.)  An OS driver can take a look at the INTerrupt table
+and try to walk along the chain of those hooks that implement the "safe hook"
+structure.  For each hook discovered, a vendor can be identified and the OS
+driver can take appropriate action.  The OS driver can mark the "flags" field
+of the "safe hook" to indicate that the driver has reviewed it already.  This
+prevents accidental re-detection, for example.
+
+MEMDISK adds one additional extension field to the "safe hook" structure, a
+pointer to a special MEMDISK structure called the "mBFT."  The mBFT is the
+"MEMDISK Boot Firmware Table" (akin to the iSCSI iBFT and the AoE aBFT).  An
+OS driver looking at MEMDISK's "safe hook" should know that this field will
+be present based on the fact that MEMDISK is the vendor identifier.
+
+The mBFT is little more than an ACPI table to prefix MEMDISK's traditional
+MEMDISK info structure (the "MDI").  The ACPI table's details are:
+
+  OEM ID. . . .: MEMDSK
+  OEM Table ID : Syslinux
+
+There is a 1-byte checksum field which covers the length of the mBFT all
+the way through to the end of the MEMDISK info structure.
+
+There is also a physical pointer to the "safe hook" structure associated
+with the MEMDISK instance.  An OS driver might use the following logic:
+
+  1. Walk INT 13h "safe hook" chain as far as possible, marking hooks as
+     having been reviewed.  For MEMDISK hooks, the driver then follows the
+     pointer to the mBFT and gathers the RAM disk details from the included
+     MDI.
+  2. The OS driver scans low memory for valid mBFTs.  MEMDISK instances that
+     have been "disconnected" from the INT 13h "safe hook" chain can be thus
+     discovered.  Looking at their associated "safe hook" structure will
+     reveal if they were indeed reviewed by the previous stage.