1SG_SES_MICROCODE(8) SG3_UTILS SG_SES_MICROCODE(8)
2
6 sg_ses_microcode - send microcode to a SCSI enclosure
7
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
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 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 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 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 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
42 Arguments to long options are mandatory for short options as well.
43 -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 -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 -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 -h, --help
89 output the usage message then exit. If used multiple times also
90 prints the mode names and their acronyms.
91 -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 -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 -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 -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 -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 -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 -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 -S, --subenc=SEID
139 SEID is the sub-enclosure identify. It defaults to 0 which is
140 the primary enclosure identifier.
141 -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 -v, --verbose
154 increase the level of verbosity, (i.e. debug output).
155 -V, --version
157 print the version string and then exit.
158
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 dmc_status [0, 0x0]
165 Use RECEIVE DIAGNOSTIC RESULTS to fetch the Download microcode
166 status dpage and print it out.
167 dmc_offs [6, 0x6]
169 Download microcode with offsets and activate.
170 dmc_offs_save [7, 0x7]
172 Download microcode with offsets, save, and activate.
173 dmc_offs_defer [14, 0xe]
175 Download microcode with offsets, save, and defer activate.
176 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 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
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 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 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
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 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 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 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 A long (operating system) timeout of 7200 seconds is set on each SEND
237 DIAGNOSTIC command.
238 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
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 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 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 sg_ses_microcode -b 4k -m dmc_offs_save -I firmware.bin /dev/sg4
268 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
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
278 Written by Douglas Gilbert.
279
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
290 sg_ses, sg_write_buffer, sg_inq(sg3_utils)
291sg3_utils-1.43 January 2018 SG_SES_MICROCODE(8)