1SG_SES_MICROCODE(8)                SG3_UTILS               SG_SES_MICROCODE(8)
2
3
4

NAME

6       sg_ses_microcode - send microcode to a SCSI enclosure
7

SYNOPSIS

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

DESCRIPTION

15       This utility attempts to download microcode to an enclosure (or one  of
16       its  sub-enclosures)  associated with the DEVICE. The process for doing
17       this is defined in the SCSI  Enclosure  Services  (SES)  standards  and
18       drafts maintained by the T10 committee.
19
20       The  process  is  to  send one or more sequences containing a SCSI SEND
21       DIAGNOSTIC command followed optionally by a RECEIVE DIAGNOSTIC  RESULTS
22       command.  The former sends a Download microcode Control diagnostic page
23       (dpage) and the latter fetches a Download microcode status dpage  which
24       can be viewed as a report on the former command.
25
26       The  default action (i.e. when the --mode=MO option is not given) is to
27       fetch the Download microcode status dpage and decode it. This does  not
28       require  the microcode (firmware) itself so the --in=FILE option is not
29       required.
30
31       The most recent reference for this utility is the draft SCSI  Enclosure
32       Services 3 (SES-3) document T10/2149-D Revision 7 at http://www.t10.org
33       .  Existing standards for SES and SES-2 are ANSI  INCITS  305-1998  and
34       ANSI INCITS 448-2008 respectively.
35
36       Most  other  support  for  SES  in this package (apart from downloading
37       microcode) can be found in the sg_ses utility. Another way of download‐
38       ing  firmware to a SCSI device is with the WRITE BUFFER command defined
39       in SPC-4, see the sg_write_buffer utility.
40

OPTIONS

42       Arguments to long options are mandatory for short options as well.
43
44       -b, --bpw=CS
45              where CS is the chunk size in bytes and should be a multiple  of
46              4.  This will be the maximum number of bytes sent per SEND DIAG‐
47              NOSTIC command.  So if CS is less than the effective  length  of
48              the  microcode  then multiple SEND DIAGNOSTIC commands are sent,
49              each taking the next chunk from the read data and increasing the
50              buffer  offset  field in the Download microcode control dpage by
51              the appropriate amount. The default is a chunk size of  0  which
52              is  interpreted as a very large number hence only one SEND DIAG‐
53              NOSTIC command will be sent.
54              The number in CS can optionally be followed by ",act" or ",acti‐
55              vate".   In  this case after the microcode has been successfully
56              sent to the DEVICE, an  additional  Download  microcode  control
57              dpage  with  its mode set to "Activate deferred microcode" [0xf]
58              is sent.
59
60       -d, --dry-run
61              the actual calls to perform SEND DIAGNOSTIC and RECEIVE DIAGNOS‐
62              TIC  RESULTS  commands are skipped when this option is given. No
63              SCSI commands are sent to the DEVICE but it is still opened  and
64              is  required  to be given.  A dummy device such as /dev/null (in
65              Unix) can be used.
66              This utility expects a "sensible" response to the RECEIVE  DIAG‐
67              NOSTIC  RESULTS  command  it sends (and will abort if it doesn't
68              receive one). So this option supplies dummy responses  with  one
69              primary  enclosure and three sub-enclosures. The dummy responses
70              include good status values.
71
72       -e, --ealsd
73              exit after last SEND DIAGNOSTIC command. A SES device should not
74              start  its  firmware  update immediately after the last received
75              "chunk" of its firmware.  Rather it should wait  till  at  least
76              one  RECEIVE  DIAGNOSTIC  RESULTS  command  is  sent to give the
77              device a chance to report any error.  However  some  devices  do
78              start  the firmware update immediately which causes the trailing
79              RECEIVE DIAGNOSTIC RESULTS command to be held up  and  often  be
80              aborted with a "target reset" error.
81              This  option causes the trailing RECEIVE DIAGNOSTIC RESULTS com‐
82              mand to be skipped. This option would be typically used with the
83              --bpw=CS option.
84              Prior  to  version  1.10  of  this utility [20180112] this (i.e.
85              skipping the last RECEIVE DIAGNOSTIC RESULTS  command)  was  the
86              default action.
87
88       -h, --help
89              output  the usage message then exit. If used multiple times also
90              prints the mode names and their acronyms.
91
92       -i, --id=ID
93              this option sets the BUFFER ID field in the  Download  microcode
94              control  dpage. ID is a value between 0 (default) and 255 inclu‐
95              sive.
96
97       -I, --in=FILE
98              read data from file FILE that will be sent with the  SEND  DIAG‐
99              NOSTIC  command.  If FILE is '-' then stdin is read until an EOF
100              is detected (this is the same action as  --raw).  Data  is  read
101              from the beginning of FILE except in the case when it is a regu‐
102              lar file and the --skip=SKIP option is given.
103
104       -l, --length=LEN
105              where LEN is the length, in bytes, of data to be written to  the
106              device.   If  not  given  (and the length cannot be deduced from
107              --in=FILE or --raw) then defaults to  zero.  If  the  option  is
108              given and the length deduced from --in=FILE or --raw is less (or
109              no data is provided), then bytes of 0xff are used as fill bytes.
110
111       -m, --mode=MO
112              this option sets the MODE. MO is a value  between  0  (which  is
113              dmc_status  and the default) and 255 inclusive. Alternatively an
114              abbreviation can be given. See the MODES section below. To  list
115              the available mode abbreviations at run time give an invalid one
116              (e.g. '--mode=xxx') or use the '-h' option.
117
118       -N, --non
119              allow for non-standard implementations that reset their Download
120              microcode engine after a RECEIVE DIAGNOSTIC RESULTS command with
121              the Download microcode status dpage is sent. When this option is
122              given  sending  that  command  and  dpage combination is avoided
123              unless an error has already occurred.
124
125       -o, --offset=OFF
126              this option  sets  the  BUFFER  OFFSET  field  in  the  Download
127              microcode  control dpage. OFF is a value between 0 (default) and
128              2**32-1 . It is a byte offset. This option  is  ignored  (and  a
129              warning sent to stderr) if the --bpw=CS option is also given.
130
131       -s, --skip=SKIP
132              this option is only active when --in=FILE is given and FILE is a
133              regular file, rather than stdin. Data is read starting  at  byte
134              offset  SKIP  to  the  end  of  file  (or  the  amount  given by
135              --length=LEN).  If not given the byte offset defaults to 0 (i.e.
136              the start of the file).
137
138       -S, --subenc=SEID
139              SEID  is  the  sub-enclosure identify. It defaults to 0 which is
140              the primary enclosure identifier.
141
142       -t, --tlength=TLEN
143              TLEN is the total length in bytes of the  microcode  to  be  (or
144              being) downloaded. It defaults to 0 which is okay in most cases.
145              This option only comes into play when TLEN is greater than  LEN.
146              In  this  case  TLEN  is sent to the SES DEVICE so that it knows
147              when it only receives LEN bytes from this  invocation,  that  it
148              should  expect  more  to  be  sent  in  the near future (e.g. by
149              another invocation). This option is only needed when sections of
150              microcode are being sent in separate invocations of this utility
151              (e.g. the microcode is spread across two files).
152
153       -v, --verbose
154              increase the level of verbosity, (i.e. debug output).
155
156       -V, --version
157              print the version string and then exit.
158

MODES

160       Following is a list accepted by the MO argument of this utility.  First
161       shown  is  an  acronym followed in square brackets by the corresponding
162       decimal and hex values that may also be given for MO.
163
164       dmc_status  [0, 0x0]
165              Use RECEIVE DIAGNOSTIC RESULTS to fetch the  Download  microcode
166              status dpage and print it out.
167
168       dmc_offs  [6, 0x6]
169              Download microcode with offsets and activate.
170
171       dmc_offs_save  [7, 0x7]
172              Download microcode with offsets, save, and activate.
173
174       dmc_offs_defer  [14, 0xe]
175              Download microcode with offsets, save, and defer activate.
176
177       activate_mc  [15, 0xf]
178              Activate deferred microcode. There is no follow-up RECEIVE DIAG‐
179              NOSTIC RESULTS to fetch  the  Download  microcode  status  dpage
180              since the DEVICE might be resetting.
181
182       Apart  from dmc_status, these are placed in the Download microcode mode
183       field in the Download microcode control dpage. In the case of  dmc_sta‐
184       tus  the  Download  microcode  status dpage is fetched with the RECEIVE
185       DIAGNOSTIC RESULTS command and decoded.
186

WHEN THE DOWNLOAD FAILS

188       Firstly, if it succeeds, this utility should stay  silent  and  return.
189       Typically vendors will change the "revision" string (which is 4 charac‐
190       ters long) whenever they release new firmware. That can be seen in  the
191       response  to  a  SCSI  INQUIRY command, for example by using the sg_inq
192       utility.  It is possible that the  device  needs  to  be  power  cycled
193       before  the  new  microcode becomes active. Also if mode dmc_offs_defer
194       [0xe] is used to download the microcode, then another  invocation  with
195       activate_mc may be needed.
196
197       If  something  goes wrong, there will typically be messages printed out
198       by this utility. The first thing to check is the  microcode  (firmware)
199       file  itself.  Is  it  designed  for the device model; has it been cor‐
200       rupted, and if downgrading (i.e. trying to reinstate  older  firmware),
201       does the vendor allow that?
202
203       Getting  new  firmware  on a device is a delicate operation that is not
204       always well defined by T10's standards and drafts. One might  speculate
205       that  they are deliberately vague. In testing this utility one vendor's
206       interpretation of the  standard  was  somewhat  surprising.  The  --non
207       option  was  added  to  cope with their interpretation. So if the above
208       suggestions don't help, try adding the --non option.
209

NOTES

211       This utility can handle a maximum size of 128  MB  of  microcode  which
212       should be sufficient for most purposes. In a system that is memory con‐
213       strained, such large allocations of memory may fail.
214
215       The user should be aware that most operating systems have limits on the
216       amount  of  data  that can be sent with one SCSI command. In Linux this
217       depends on the pass through mechanism used (e.g. block SG_IO or the  sg
218       driver) and various setting in sysfs in the Linux lk 2.6/3 series (e.g.
219       /sys/block/sda/queue/max_sectors_kb). Devices (i.e. logical units) also
220       typically  have limits on the maximum amount of data they can handle in
221       one command. These two limitations suggest that  modes  containing  the
222       word  "offset"  together  with  the  --bpw=CS  option  are  required as
223       firmware files get larger and larger. And CS can be  quite  small,  for
224       example  4096  bytes,  resulting in many SEND DIAGNOSTIC commands being
225       sent.
226
227       The exact error from the non-standard implementation was a sense key of
228       ILLEGAL  REQUEST  and  an  asc/ascq  code of 0x26,0x0 which is "Invalid
229       field in parameter list". If that is seen  try  again  with  the  --non
230       option.
231
232       Downloading incorrect microcode into a device has the ability to render
233       that device inoperable. One would hope that the device vendor  verifies
234       the data before activating it.
235
236       A  long  (operating system) timeout of 7200 seconds is set on each SEND
237       DIAGNOSTIC command.
238
239       All numbers given with options are assumed  to  be  decimal.   Alterna‐
240       tively  numerical values can be given in hexadecimal preceded by either
241       "0x" or "0X" (or has a trailing "h" or "H").
242

EXAMPLES

244       If no microcode/firmware file is given then this  utility  fetches  and
245       decodes  the  Download microcode status dpage which could possibly show
246       another initiator in the process of updating  the  microcode.  Even  if
247       that  is happening, fetching the status page should not cause any prob‐
248       lems:
249
250         sg_ses_microcode /dev/sg3
251       Download microcode status diagnostic page:
252         number of secondary sub-enclosures: 0
253         generation code: 0x0
254          sub-enclosure identifier: 0 [primary]
255            download microcode status:  No  download  microcode  operation  in
256       progress [0x0]
257            download microcode additional status: 0x0
258            download microcode maximum size: 1048576 bytes
259            download microcode expected buffer id: 0x0
260            download microcode expected buffer id offset: 0
261
262       The  following  sends new microcode/firmware to an enclosure. Sending a
263       1.5 MB file in one command caused the enclosure to lock up  temporarily
264       and  did  not update the firmware. Breaking the firmware file into 4 KB
265       chunks (an educated guess) was more successful:
266
267         sg_ses_microcode -b 4k -m dmc_offs_save -I firmware.bin /dev/sg4
268
269       The firmware update occurred in the following  enclosure  power  cycle.
270       With a modern enclosure the Extended Inquiry VPD page gives indications
271       in which situations a firmware upgrade will take place.
272

EXIT STATUS

274       The exit status of sg_ses_microcode is 0 when it is successful.  Other‐
275       wise see the sg3_utils(8) man page.
276

AUTHORS

278       Written by Douglas Gilbert.
279

REPORTING BUGS

281       Report bugs to <dgilbert at interlog dot com>.
282
284       Copyright © 2014-2018 Douglas Gilbert
285       This  software is distributed under a FreeBSD license. There is NO war‐
286       ranty; not even for MERCHANTABILITY or FITNESS FOR  A  PARTICULAR  PUR‐
287       POSE.
288

SEE ALSO

290       sg_ses, sg_write_buffer, sg_inq(sg3_utils)
291
292
293
294sg3_utils-1.43                   January 2018              SG_SES_MICROCODE(8)
Impressum