{ "mode": "man", "parameter": "sg_ses_microcode", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/sg_ses_microcode/8/json", "generated": "2026-06-14T04:14:31Z", "synopsis": "sgsesmicrocode [--bpw=CS] [--dry-run] [--ealsd] [--help] [--id=ID] [--in=FILE]\n[--length=LEN] [--mode=MO] [--non] [--offset=OFF] [--skip=SKIP] [--subenc=MS]\n[--tlength=TLEN] [--verbose] [--version] DEVICE", "sections": { "NAME": { "content": "sgsesmicrocode - send microcode to a SCSI enclosure\n", "subsections": [] }, "SYNOPSIS": { "content": "sgsesmicrocode [--bpw=CS] [--dry-run] [--ealsd] [--help] [--id=ID] [--in=FILE]\n[--length=LEN] [--mode=MO] [--non] [--offset=OFF] [--skip=SKIP] [--subenc=MS]\n[--tlength=TLEN] [--verbose] [--version] DEVICE\n", "subsections": [] }, "DESCRIPTION": { "content": "This utility attempts to download microcode to an enclosure (or one of its sub-enclosures)\nassociated with the DEVICE. The process for doing this is defined in the SCSI Enclosure Ser‐\nvices (SES) standards and drafts maintained by the T10 committee.\n\nThe process is to send one or more sequences containing a SCSI SEND DIAGNOSTIC command fol‐\nlowed optionally by a RECEIVE DIAGNOSTIC RESULTS command. The former sends a Download mi‐\ncrocode Control diagnostic page (dpage) and the latter fetches a Download microcode status\ndpage which can be viewed as a report on the former command.\n\nThe default action (i.e. when the --mode=MO option is not given) is to fetch the Download mi‐\ncrocode status dpage and decode it. This does not require the microcode (firmware) itself so\nthe --in=FILE option is not required.\n\nThe most recent reference for this utility is the draft SCSI Enclosure Services 3 (SES-3)\ndocument T10/2149-D Revision 7 at http://www.t10.org . Existing standards for SES and SES-2\nare ANSI INCITS 305-1998 and ANSI INCITS 448-2008 respectively.\n\nMost other support for SES in this package (apart from downloading microcode) can be found in\nthe sgses utility. Another way of downloading firmware to a SCSI device is with the WRITE\nBUFFER command defined in SPC-4, see the sgwritebuffer utility.\n", "subsections": [] }, "OPTIONS": { "content": "Arguments to long options are mandatory for short options as well.\n", "subsections": [ { "name": "-b --bpw", "content": "where CS is the chunk size in bytes and should be a multiple of 4. This will be the\nmaximum number of bytes sent per SEND DIAGNOSTIC command. So if CS is less than the\neffective length of the microcode then multiple SEND DIAGNOSTIC commands are sent,\neach taking the next chunk from the read data and increasing the buffer offset field\nin the Download microcode control dpage by the appropriate amount. The default is a\nchunk size of 0 which is interpreted as a very large number hence only one SEND DIAG‐\nNOSTIC command will be sent.\nThe number in CS can optionally be followed by \",act\" or \",activate\". In this case\nafter the microcode has been successfully sent to the DEVICE, an additional Download\nmicrocode control dpage with its mode set to \"Activate deferred microcode\" [0xf] is\nsent.\n", "flag": "-b", "long": "--bpw" }, { "name": "-d --dry-run", "content": "the actual calls to perform SEND DIAGNOSTIC and RECEIVE DIAGNOSTIC RESULTS commands\nare skipped when this option is given. No SCSI commands are sent to the DEVICE but it\nis still opened and is required to be given. A dummy device such as /dev/null (in\nUnix) can be used.\nThis utility expects a \"sensible\" response to the RECEIVE DIAGNOSTIC RESULTS command\nit sends (and will abort if it doesn't receive one). So this option supplies dummy re‐\nsponses with one primary enclosure and three sub-enclosures. The dummy responses in‐\nclude good status values.\n", "flag": "-d", "long": "--dry-run" }, { "name": "-e --ealsd", "content": "exit after last SEND DIAGNOSTIC command. A SES device should not start its firmware\nupdate immediately after the last received \"chunk\" of its firmware. Rather it should\nwait till at least one RECEIVE DIAGNOSTIC RESULTS command is sent to give the device a\nchance to report any error. However some devices do start the firmware update immedi‐\nately which causes the trailing RECEIVE DIAGNOSTIC RESULTS command to be held up and\noften be aborted with a \"target reset\" error.\nThis option causes the trailing RECEIVE DIAGNOSTIC RESULTS command to be skipped. This\noption would be typically used with the --bpw=CS option.\nPrior to version 1.10 of this utility [20180112] this (i.e. skipping the last RECEIVE\nDIAGNOSTIC RESULTS command) was the default action.\n", "flag": "-e", "long": "--ealsd" }, { "name": "-h --help", "content": "output the usage message then exit. If used multiple times also prints the mode names\nand their acronyms.\n", "flag": "-h", "long": "--help" }, { "name": "-i --id", "content": "this option sets the BUFFER ID field in the Download microcode control dpage. ID is a\nvalue between 0 (default) and 255 inclusive.\n", "flag": "-i", "long": "--id" }, { "name": "-I --in", "content": "read data from file FILE that will be sent with the SEND DIAGNOSTIC command. If FILE\nis '-' then stdin is read until an EOF is detected (this is the same action as --raw).\nData is read from the beginning of FILE except in the case when it is a regular file\nand the --skip=SKIP option is given.\n", "flag": "-I", "long": "--in" }, { "name": "-l --length", "content": "where LEN is the length, in bytes, of data to be written to the device. If not given\n(and the length cannot be deduced from --in=FILE or --raw) then defaults to zero. If\nthe option is given and the length deduced from --in=FILE or --raw is less (or no data\nis provided), then bytes of 0xff are used as fill bytes.\n", "flag": "-l", "long": "--length" }, { "name": "-m --mode", "content": "this option sets the MODE. MO is a value between 0 (which is dmcstatus and the de‐\nfault) and 255 inclusive. Alternatively an abbreviation can be given. See the MODES\nsection below. To list the available mode abbreviations at run time give an invalid\none (e.g. '--mode=xxx') or use the '-h' option.\n", "flag": "-m", "long": "--mode" }, { "name": "-N --non", "content": "allow for non-standard implementations that reset their Download microcode engine af‐\nter a RECEIVE DIAGNOSTIC RESULTS command with the Download microcode status dpage is\nsent. When this option is given sending that command and dpage combination is avoided\nunless an error has already occurred.\n", "flag": "-N", "long": "--non" }, { "name": "-o --offset", "content": "this option sets the BUFFER OFFSET field in the Download microcode control dpage. OFF\nis a value between 0 (default) and 232-1 . It is a byte offset. This option is ig‐\nnored (and a warning sent to stderr) if the --bpw=CS option is also given.\n", "flag": "-o", "long": "--offset" }, { "name": "-s --skip", "content": "this option is only active when --in=FILE is given and FILE is a regular file, rather\nthan stdin. Data is read starting at byte offset SKIP to the end of file (or the\namount given by --length=LEN). If not given the byte offset defaults to 0 (i.e. the\nstart of the file).\n", "flag": "-s", "long": "--skip" }, { "name": "-S --subenc", "content": "SEID is the sub-enclosure identify. It defaults to 0 which is the primary enclosure\nidentifier.\n", "flag": "-S", "long": "--subenc" }, { "name": "-t --tlength", "content": "TLEN is the total length in bytes of the microcode to be (or being) downloaded. It de‐\nfaults to 0 which is okay in most cases. This option only comes into play when TLEN is\ngreater than LEN. In this case TLEN is sent to the SES DEVICE so that it knows when it\nonly receives LEN bytes from this invocation, that it should expect more to be sent in\nthe near future (e.g. by another invocation). This option is only needed when sections\nof microcode are being sent in separate invocations of this utility (e.g. the mi‐\ncrocode is spread across two files).\n", "flag": "-t", "long": "--tlength" }, { "name": "-v --verbose", "content": "increase the level of verbosity, (i.e. debug output).\n", "flag": "-v", "long": "--verbose" }, { "name": "-V --version", "content": "print the version string and then exit.\n", "flag": "-V", "long": "--version" } ] }, "MODES": { "content": "Following is a list accepted by the MO argument of this utility. First shown is an acronym\nfollowed in square brackets by the corresponding decimal and hex values that may also be\ngiven for MO.\n\ndmcstatus [0, 0x0]\nUse RECEIVE DIAGNOSTIC RESULTS to fetch the Download microcode status dpage and print\nit out.\n\ndmcoffs [6, 0x6]\nDownload microcode with offsets and activate.\n\ndmcoffssave [7, 0x7]\nDownload microcode with offsets, save, and activate.\n\ndmcoffsdefer [14, 0xe]\nDownload microcode with offsets, save, and defer activate.\n\nactivatemc [15, 0xf]\nActivate deferred microcode. There is no follow-up RECEIVE DIAGNOSTIC RESULTS to fetch\nthe Download microcode status dpage since the DEVICE might be resetting.\n\nApart from dmcstatus, these are placed in the Download microcode mode field in the Download\nmicrocode control dpage. In the case of dmcstatus the Download microcode status dpage is\nfetched with the RECEIVE DIAGNOSTIC RESULTS command and decoded.\n", "subsections": [] }, "WHEN THE DOWNLOAD FAILS": { "content": "Firstly, if it succeeds, this utility should stay silent and return. Typically vendors will\nchange the \"revision\" string (which is 4 characters long) whenever they release new firmware.\nThat can be seen in the response to a SCSI INQUIRY command, for example by using the sginq\nutility. It is possible that the device needs to be power cycled before the new microcode\nbecomes active. Also if mode dmcoffsdefer [0xe] is used to download the microcode, then an‐\nother invocation with activatemc may be needed.\n\nIf something goes wrong, there will typically be messages printed out by this utility. The\nfirst thing to check is the microcode (firmware) file itself. Is it designed for the device\nmodel; has it been corrupted, and if downgrading (i.e. trying to reinstate older firmware),\ndoes the vendor allow that?\n\nGetting new firmware on a device is a delicate operation that is not always well defined by\nT10's standards and drafts. One might speculate that they are deliberately vague. In testing\nthis utility one vendor's interpretation of the standard was somewhat surprising. The --non\noption was added to cope with their interpretation. So if the above suggestions don't help,\ntry adding the --non option.\n", "subsections": [] }, "NOTES": { "content": "This utility can handle a maximum size of 128 MB of microcode which should be sufficient for\nmost purposes. In a system that is memory constrained, such large allocations of memory may\nfail.\n\nThe user should be aware that most operating systems have limits on the amount of data that\ncan be sent with one SCSI command. In Linux this depends on the pass through mechanism used\n(e.g. block SGIO or the sg driver) and various setting in sysfs in the Linux lk 2.6/3 series\n(e.g. /sys/block/sda/queue/maxsectorskb). Devices (i.e. logical units) also typically have\nlimits on the maximum amount of data they can handle in one command. These two limitations\nsuggest that modes containing the word \"offset\" together with the --bpw=CS option are re‐\nquired as firmware files get larger and larger. And CS can be quite small, for example 4096\nbytes, resulting in many SEND DIAGNOSTIC commands being sent.\n\nThe exact error from the non-standard implementation was a sense key of ILLEGAL REQUEST and\nan asc/ascq code of 0x26,0x0 which is \"Invalid field in parameter list\". If that is seen try\nagain with the --non option.\n\nDownloading incorrect microcode into a device has the ability to render that device inopera‐\nble. One would hope that the device vendor verifies the data before activating it.\n\nA long (operating system) timeout of 7200 seconds is set on each SEND DIAGNOSTIC command.\n\nAll numbers given with options are assumed to be decimal. Alternatively numerical values can\nbe given in hexadecimal preceded by either \"0x\" or \"0X\" (or has a trailing \"h\" or \"H\").\n", "subsections": [] }, "EXAMPLES": { "content": "If no microcode/firmware file is given then this utility fetches and decodes the Download mi‐\ncrocode status dpage which could possibly show another initiator in the process of updating\nthe microcode. Even if that is happening, fetching the status page should not cause any prob‐\nlems:\n\nsgsesmicrocode /dev/sg3\nDownload microcode status diagnostic page:\nnumber of secondary sub-enclosures: 0\ngeneration code: 0x0\nsub-enclosure identifier: 0 [primary]\ndownload microcode status: No download microcode operation in progress [0x0]\ndownload microcode additional status: 0x0\ndownload microcode maximum size: 1048576 bytes\ndownload microcode expected buffer id: 0x0\ndownload microcode expected buffer id offset: 0\n\nThe following sends new microcode/firmware to an enclosure. Sending a 1.5 MB file in one com‐\nmand caused the enclosure to lock up temporarily and did not update the firmware. Breaking\nthe firmware file into 4 KB chunks (an educated guess) was more successful:\n\nsgsesmicrocode -b 4k -m dmcoffssave -I firmware.bin /dev/sg4\n\nThe firmware update occurred in the following enclosure power cycle. With a modern enclosure\nthe Extended Inquiry VPD page gives indications in which situations a firmware upgrade will\ntake place.\n", "subsections": [] }, "EXIT STATUS": { "content": "The exit status of sgsesmicrocode is 0 when it is successful. Otherwise see the\nsg3utils(8) man page.\n", "subsections": [] }, "AUTHORS": { "content": "Written by Douglas Gilbert.\n", "subsections": [] }, "REPORTING BUGS": { "content": "Report bugs to .\n", "subsections": [] }, "COPYRIGHT": { "content": "Copyright © 2014-2018 Douglas Gilbert\nThis software is distributed under a FreeBSD license. There is NO warranty; not even for MER‐\nCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n", "subsections": [] }, "SEE ALSO": { "content": "sgses, sgwritebuffer, sginq(sg3utils)\n\n\n\nsg3utils-1.43 January 2018 SGSESMICROCODE(8)", "subsections": [] } }, "summary": "sgsesmicrocode - send microcode to a SCSI enclosure", "flags": [ { "flag": "-b", "long": "--bpw", "arg": null, "description": "where CS is the chunk size in bytes and should be a multiple of 4. This will be the maximum number of bytes sent per SEND DIAGNOSTIC command. So if CS is less than the effective length of the microcode then multiple SEND DIAGNOSTIC commands are sent, each taking the next chunk from the read data and increasing the buffer offset field in the Download microcode control dpage by the appropriate amount. The default is a chunk size of 0 which is interpreted as a very large number hence only one SEND DIAG‐ NOSTIC command will be sent. The number in CS can optionally be followed by \",act\" or \",activate\". In this case after the microcode has been successfully sent to the DEVICE, an additional Download microcode control dpage with its mode set to \"Activate deferred microcode\" [0xf] is sent." }, { "flag": "-d", "long": "--dry-run", "arg": null, "description": "the actual calls to perform SEND DIAGNOSTIC and RECEIVE DIAGNOSTIC RESULTS commands are skipped when this option is given. No SCSI commands are sent to the DEVICE but it is still opened and is required to be given. A dummy device such as /dev/null (in Unix) can be used. This utility expects a \"sensible\" response to the RECEIVE DIAGNOSTIC RESULTS command it sends (and will abort if it doesn't receive one). So this option supplies dummy re‐ sponses with one primary enclosure and three sub-enclosures. The dummy responses in‐ clude good status values." }, { "flag": "-e", "long": "--ealsd", "arg": null, "description": "exit after last SEND DIAGNOSTIC command. A SES device should not start its firmware update immediately after the last received \"chunk\" of its firmware. Rather it should wait till at least one RECEIVE DIAGNOSTIC RESULTS command is sent to give the device a chance to report any error. However some devices do start the firmware update immedi‐ ately which causes the trailing RECEIVE DIAGNOSTIC RESULTS command to be held up and often be aborted with a \"target reset\" error. This option causes the trailing RECEIVE DIAGNOSTIC RESULTS command to be skipped. This option would be typically used with the --bpw=CS option. Prior to version 1.10 of this utility [20180112] this (i.e. skipping the last RECEIVE DIAGNOSTIC RESULTS command) was the default action." }, { "flag": "-h", "long": "--help", "arg": null, "description": "output the usage message then exit. If used multiple times also prints the mode names and their acronyms." }, { "flag": "-i", "long": "--id", "arg": null, "description": "this option sets the BUFFER ID field in the Download microcode control dpage. ID is a value between 0 (default) and 255 inclusive." }, { "flag": "-I", "long": "--in", "arg": null, "description": "read data from file FILE that will be sent with the SEND DIAGNOSTIC command. If FILE is '-' then stdin is read until an EOF is detected (this is the same action as --raw). Data is read from the beginning of FILE except in the case when it is a regular file and the --skip=SKIP option is given." }, { "flag": "-l", "long": "--length", "arg": null, "description": "where LEN is the length, in bytes, of data to be written to the device. If not given (and the length cannot be deduced from --in=FILE or --raw) then defaults to zero. If the option is given and the length deduced from --in=FILE or --raw is less (or no data is provided), then bytes of 0xff are used as fill bytes." }, { "flag": "-m", "long": "--mode", "arg": null, "description": "this option sets the MODE. MO is a value between 0 (which is dmcstatus and the de‐ fault) and 255 inclusive. Alternatively an abbreviation can be given. See the MODES section below. To list the available mode abbreviations at run time give an invalid one (e.g. '--mode=xxx') or use the '-h' option." }, { "flag": "-N", "long": "--non", "arg": null, "description": "allow for non-standard implementations that reset their Download microcode engine af‐ ter a RECEIVE DIAGNOSTIC RESULTS command with the Download microcode status dpage is sent. When this option is given sending that command and dpage combination is avoided unless an error has already occurred." }, { "flag": "-o", "long": "--offset", "arg": null, "description": "this option sets the BUFFER OFFSET field in the Download microcode control dpage. OFF is a value between 0 (default) and 232-1 . It is a byte offset. This option is ig‐ nored (and a warning sent to stderr) if the --bpw=CS option is also given." }, { "flag": "-s", "long": "--skip", "arg": null, "description": "this option is only active when --in=FILE is given and FILE is a regular file, rather than stdin. Data is read starting at byte offset SKIP to the end of file (or the amount given by --length=LEN). If not given the byte offset defaults to 0 (i.e. the start of the file)." }, { "flag": "-S", "long": "--subenc", "arg": null, "description": "SEID is the sub-enclosure identify. It defaults to 0 which is the primary enclosure identifier." }, { "flag": "-t", "long": "--tlength", "arg": null, "description": "TLEN is the total length in bytes of the microcode to be (or being) downloaded. It de‐ faults to 0 which is okay in most cases. This option only comes into play when TLEN is greater than LEN. In this case TLEN is sent to the SES DEVICE so that it knows when it only receives LEN bytes from this invocation, that it should expect more to be sent in the near future (e.g. by another invocation). This option is only needed when sections of microcode are being sent in separate invocations of this utility (e.g. the mi‐ crocode is spread across two files)." }, { "flag": "-v", "long": "--verbose", "arg": null, "description": "increase the level of verbosity, (i.e. debug output)." }, { "flag": "-V", "long": "--version", "arg": null, "description": "print the version string and then exit." } ], "examples": [ "If no microcode/firmware file is given then this utility fetches and decodes the Download mi‐", "crocode status dpage which could possibly show another initiator in the process of updating", "the microcode. Even if that is happening, fetching the status page should not cause any prob‐", "lems:", "sgsesmicrocode /dev/sg3", "Download microcode status diagnostic page:", "number of secondary sub-enclosures: 0", "generation code: 0x0", "sub-enclosure identifier: 0 [primary]", "download microcode status: No download microcode operation in progress [0x0]", "download microcode additional status: 0x0", "download microcode maximum size: 1048576 bytes", "download microcode expected buffer id: 0x0", "download microcode expected buffer id offset: 0", "The following sends new microcode/firmware to an enclosure. Sending a 1.5 MB file in one com‐", "mand caused the enclosure to lock up temporarily and did not update the firmware. Breaking", "the firmware file into 4 KB chunks (an educated guess) was more successful:", "sgsesmicrocode -b 4k -m dmcoffssave -I firmware.bin /dev/sg4", "The firmware update occurred in the following enclosure power cycle. With a modern enclosure", "the Extended Inquiry VPD page gives indications in which situations a firmware upgrade will", "take place." ], "see_also": [ { "name": "sginq", "section": "sg3utils", "url": "https://www.chedong.com/phpMan.php/man/sginq/sg3utils/json" } ] }