Provided by: sg3-utils_1.46-1ubuntu0.22.04.1_amd64 bug

NAME

       sg_ses_microcode - send microcode to a SCSI enclosure

SYNOPSIS

       sg_ses_microcode   [--bpw=CS]   [--dry-run]   [--ealsd]   [--help]  [--id=ID]  [--in=FILE]
       [--length=LEN]   [--mode=MO]   [--non]    [--offset=OFF]    [--skip=SKIP]    [--subenc=MS]
       [--tlength=TLEN] [--verbose] [--version] DEVICE

DESCRIPTION

       This utility attempts to download microcode to an enclosure (or one of its sub-enclosures)
       associated with the DEVICE. The process for doing this is defined in  the  SCSI  Enclosure
       Services (SES) standards and drafts maintained by the T10 committee.

       The  process  is  to  send one or more sequences containing a SCSI SEND DIAGNOSTIC command
       followed optionally by a RECEIVE DIAGNOSTIC RESULTS command. The former sends  a  Download
       microcode  Control  diagnostic  page  (dpage)  and the latter fetches a Download microcode
       status dpage which can be viewed as a report on the former command.

       The default action (i.e. when the --mode=MO option is not given) is to fetch the  Download
       microcode  status  dpage  and  decode  it.  This does not require the microcode (firmware)
       itself so the --in=FILE option is not required.

       The most recent reference for this utility is the draft SCSI Enclosure Services 3  (SES-3)
       document  T10/2149-D  Revision  7  at http://www.t10.org .  Existing standards for SES and
       SES-2 are ANSI INCITS 305-1998 and ANSI INCITS 448-2008 respectively.

       Most other support for SES in this package (apart from downloading microcode) can be found
       in  the  sg_ses  utility. Another way of downloading firmware to a SCSI device is with the
       WRITE BUFFER command defined in SPC-4, see the sg_write_buffer utility.

OPTIONS

       Arguments to long options are mandatory for short options as well.

       -b, --bpw=CS
              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 DIAGNOSTIC 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.

       -d, --dry-run
              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 responses with one primary enclosure and three  sub-enclosures.  The
              dummy responses include good status values.

       -e, --ealsd
              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  immediately 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.

       -h, --help
              output the usage message then exit. If used multiple times  also  prints  the  mode
              names and their acronyms.

       -i, --id=ID
              this option sets the BUFFER ID field in the Download microcode control dpage. ID is
              a value between 0 (default) and 255 inclusive.

       -I, --in=FILE
              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.

       -l, --length=LEN
              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.

       -m, --mode=MO
              this option sets the MODE. MO is a value between 0 (which  is  dmc_status  and  the
              default)  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.

       -N, --non
              allow  for  non-standard implementations that reset their Download microcode engine
              after 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.

       -o, --offset=OFF
              this option sets the BUFFER OFFSET field in the Download microcode  control  dpage.
              OFF  is  a value between 0 (default) and 2**32-1 . It is a byte offset. This option
              is ignored (and a warning sent to stderr) if the --bpw=CS option is also given.

       -s, --skip=SKIP
              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).

       -S, --subenc=SEID
              SEID is the sub-enclosure identify. It defaults to 0 which is the primary enclosure
              identifier.

       -t, --tlength=TLEN
              TLEN is the total length in bytes of the microcode to be (or being) downloaded.  It
              defaults  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 microcode is spread across two files).

       -v, --verbose
              increase the level of verbosity, (i.e. debug output).

       -V, --version
              print the version string and then exit.

MODES

       Following is a list accepted by the MO argument  of  this  utility.   First  shown  is  an
       acronym  followed  in square brackets by the corresponding decimal and hex values that may
       also be given for MO.

       dmc_status  [0, 0x0]
              Use RECEIVE DIAGNOSTIC RESULTS to fetch the Download  microcode  status  dpage  and
              print it out.

       dmc_offs  [6, 0x6]
              Download microcode with offsets and activate.

       dmc_offs_save  [7, 0x7]
              Download microcode with offsets, save, and activate.

       dmc_offs_defer  [14, 0xe]
              Download microcode with offsets, save, and defer activate.

       activate_mc  [15, 0xf]
              Activate  deferred  microcode.  There is no follow-up RECEIVE DIAGNOSTIC RESULTS to
              fetch the Download microcode status dpage since the DEVICE might be resetting.

       Apart from dmc_status, these are placed in  the  Download  microcode  mode  field  in  the
       Download  microcode control dpage. In the case of dmc_status the Download microcode status
       dpage is fetched with the RECEIVE DIAGNOSTIC RESULTS command and decoded.

WHEN THE DOWNLOAD FAILS

       Firstly, if it succeeds, this utility should stay silent and  return.   Typically  vendors
       will  change  the "revision" string (which is 4 characters long) whenever they release new
       firmware. That can be seen in the response to a SCSI INQUIRY command, for example by using
       the  sg_inq  utility.   It is possible that the device needs to be power cycled before the
       new microcode becomes active. Also if mode dmc_offs_defer [0xe] is used  to  download  the
       microcode, then another invocation with activate_mc may be needed.

       If something goes wrong, there will typically be messages printed out by this utility. The
       first thing to check is the microcode (firmware) file  itself.  Is  it  designed  for  the
       device  model;  has  it been corrupted, and if downgrading (i.e. trying to reinstate older
       firmware), does the vendor allow that?

       Getting new firmware on a device is a delicate operation that is not always  well  defined
       by  T10's  standards  and drafts. One might speculate that they are deliberately vague. In
       testing this utility one vendor's interpretation of the standard was somewhat  surprising.
       The  --non option was added to cope with their interpretation. So if the above suggestions
       don't help, try adding the --non option.

NOTES

       This utility can handle a maximum size of 128 MB of microcode which should  be  sufficient
       for  most  purposes.  In  a  system  that is memory constrained, such large allocations of
       memory may fail.

       The user should be aware that most operating systems have limits on  the  amount  of  data
       that  can  be  sent  with  one  SCSI  command.  In  Linux this depends on the pass through
       mechanism used (e.g. block SG_IO or the sg driver) and various setting  in  sysfs  in  the
       Linux  lk  2.6/3  series (e.g. /sys/block/sda/queue/max_sectors_kb). Devices (i.e. logical
       units) also typically have limits on the maximum amount of data they  can  handle  in  one
       command.  These  two  limitations suggest that modes containing the word "offset" together
       with the --bpw=CS option are required as firmware files get larger and larger. And CS  can
       be  quite  small, for example 4096 bytes, resulting in many SEND DIAGNOSTIC commands being
       sent.

       The exact error from the non-standard implementation was a sense key  of  ILLEGAL  REQUEST
       and  an  asc/ascq  code of 0x26,0x0 which is "Invalid field in parameter list". If that is
       seen try again with the --non option.

       Downloading incorrect microcode into a device  has  the  ability  to  render  that  device
       inoperable. One would hope that the device vendor verifies the data before activating it.

       A long (operating system) timeout of 7200 seconds is set on each SEND DIAGNOSTIC command.

       All  numbers given with options are assumed to be decimal.  Alternatively numerical values
       can be given in hexadecimal preceded by either "0x" or "0X" (or  has  a  trailing  "h"  or
       "H").

EXAMPLES

       If  no microcode/firmware file is given then this utility fetches and decodes the Download
       microcode 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 problems:

         sg_ses_microcode /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
       command  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:

         sg_ses_microcode -b 4k -m dmc_offs_save -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.

EXIT STATUS

       The exit status of sg_ses_microcode  is  0  when  it  is  successful.  Otherwise  see  the
       sg3_utils(8) man page.

AUTHORS

       Written by Douglas Gilbert.

REPORTING BUGS

       Report bugs to <dgilbert at interlog dot com>.

COPYRIGHT

       Copyright © 2014-2018 Douglas Gilbert
       This  software  is distributed under a FreeBSD license. There is NO warranty; not even for
       MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

SEE ALSO

       sg_ses, sg_write_buffer, sg_inq(sg3_utils)