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
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.
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
[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
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.
projects / profile / ivi / syslinux.git / blobdiff