]> $Id: MDF-Specification.sgml,v 1.1 2001/04/20 17:28:48 nico Exp $ NicoSchmoigl A binary orientated network-wide protocol for submitting information about bad memory modules. The MDF (Memory Data Format) procotol is a block-orientated, abstract protocol, normally (but not necessarily) restricted to files and to memory areas. The block size depends on the amount of data specified with the given command. A sequence of MDF commands (see later) describes one (or more) memory modules (and its bad areas) uniquely.

A MDF command consists at least of the following bytes: offsettypenamedescription 0x00 unsigned 8-bit command Describes the type of action which should be taken when reading this command; see reference below for more details which actions can be triggered. 0x01 unsigned 16-bit network order sub-command A (not-yet-used) sub command for specifing the exact action which should be taken 0x03 unsigned 8-bit length Stores how many bytes are in the data area which will follow this MDF command Summarized, you can see that this structure has a total length of four bytes. Please note that after these bytes, there might be additional data which length is stated in the length field. Note that therefore the maximal amount of bytes in the data area is always restricted to 255 bytes; a length of zero means that no additional data is available.

A sequence of MDF commands is one (or normally more) MDF commands concatinated in a specific, user-defined order. Please note that between the given commands there may be additional data as already stated during the definition of the command. Therefore a valid sequence may look like this: | cmd1 | subcmd1 | len1 | ***** data1 ***** | cmd2 | subcmd2 | len2 | cmd3 | subcmd3 | len3 | ** data3 ** | But please note that the length of the data1-field is always the same as len1 (the same on data3 and len3, too, for sure!)

Every bit combination of the command field in a MDF command symbolizes a certain action to be performed. Here are their meanings: content in the command field abbrevation description0x01MDFCMD_VERSIONDefines the current version of this protocol0xffMDFCMD_ENDThe MDF protocol ends here; all data after this mark should not be interpretated as MDF commands0x10MDFCMD_MODULENAMEDefinition of module identification name0x11MDFCMD_SIZEDefinition of module size0x20MDFCMD_PATTERNSubmission of a pattern line for bad spots in a memory module All other bytes not specified above are still unused; their meaning is not defined here. Therefore they should not be used in practice. The commands above will now be discussed:

command: MDFCMD_VERSION sub-command: see description length: always 0 data: nothing

Defines the protocol version. The sub-command holds the version number. As this is the first release, sub-command should be always 1. Further releases will always be compatible to earlier versions. Therefore, unknown commands should be skipped without taking any action. Important:Any MDF data should begin with this command to make sure that the interpreter may use the correct command set

command: MDFCMD_END sub-command: does not matter length: always 0 data: nothing

This tells the interpreter that beyond this mark, no new command should be looked at. This features enables the MDF specification to be included into other (network) protocols.

command: MDFCMD_MODULENAME sub-command: always 0 length: see description data: see description

MDFCMD_MODULENAME starts a new module definition. There is no "MODULE END" command; the next MDFCMD_MODULENAME starts a new module, closing the old one. In the field data, you must specify an unique (globally, if possible) qualifier. The length of this qualifier is stored in the length field. The qualifier can consist of any byte combination. Please do not use the 0x0 byte as this may be confusing. It is recommended to use only tty-characters.

requires: a MDFCMD_MODULENAME must be prior this command command: MDFCMD_MODULESIZE sub-command: always 0 length: see description (recommendation: 4) data: see description

Defines the maximal size of the modules, defined by latest MDFCMD_MODULENAME command. If specified more than once for a module, the last MDFCMD_MODULESIZE is the valid one. The actual module size is store in the data field. The field length stores its length. The data is in network order. The unit of the size is in (pure) bytes. It is recommended to use an unsigned 32-bit value in network order for submission.

command: MDFCMD_PATTERN sub-command: depends on type length: depends on type data: see description

There are several types of patterns: sub-commandtypecomment0x0000ANCIENTPlease not use this pattern type - it is too old0x0001unused0x0002V2Due to the lack of upper bounds, please do not use the standard V2-type0x0003V2-with-uboundThis is the preferred pattern type

A V2-with-ubound structure consists of four fields: offsettypenamedescription 0x00 unsigned 32-bit network order lbound contains the lower bound of the pattern 0x04 unsigned 32-bit network order mask contains the general mask of the pattern 0x08 unsigned 32-bit network order ubound contains the upper bound of the pattern 0x0b unsigned 32-bit network order offset contains the (logical) offset of the pattern If you need futher information what the single fields do, please read the BadMEM Pattern Specification, which you can download from http://badmem.sourceforge.net Please note that the normal length of a V2-with-ubound structure is 16 bytes.

The following sequence of MDF commands is a recommended prototype: MDFCMD_VERSION first MDFCMD_MODULENAME first MDFCMD_MODULESIZE zero, one or more MDFCMD_PATTERN second MDFCMD_MODULENAME second MDFCMD_MODULESIZE zero, one or more MDFCMD_PATTERN repeat the last three steps for any module you want to define MDFCMD_END