Merge branch 'json' into libupload
[profile/ivi/syslinux.git] / doc / memdisk.txt
index 8a308f1..0d6293d 100644 (file)
@@ -9,6 +9,9 @@ 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.
 
+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
@@ -129,15 +132,29 @@ g) The following option can be used to set the real-mode stack size.
 
    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)
+
+i) The following standard Linux option will mark memory as reserved.
+   Please note that the Syslinux core already loads MEMDISK and its
+   initrd below this point:
+
+   mem=size    Mark available memory above this point as Reserved.
+
 
 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
@@ -180,13 +197,14 @@ The MEMDISK info structure currently contains:
        [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    Currently unused
+       [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
 
@@ -241,3 +259,40 @@ method for this.
        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.