d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
d4fba56212
freebsd-nq/sbin/camcontrol/fwdownload.c

1058 lines
29 KiB
C
Raw Normal View History

Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
/*-
various: general adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. No functional change intended.
2017-11-27 15:37:16 +00:00
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
*
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
* Copyright (c) 2011 Sandvine Incorporated. All rights reserved.
* Copyright (c) 2002-2011 Andre Albsmeier <andre@albsmeier.net>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer,
* without modification, immediately at the beginning of the file.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
Restore comment with credit to Marc Frajola. fwdownload.c is derived from Andre Albsmeier's fwdownload.c, which was written from scratch but was inspired by Marc's original idea and code.
2011-12-02 15:47:05 +00:00
/*
* This software is derived from Andre Albsmeier's fwprog.c which contained
* the following note:
*
* Many thanks goes to Marc Frajola <marc@terasolutions.com> from
* TeraSolutions for the initial idea and his programme for upgrading
* the firmware of I*M DDYS drives.
*/
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
/*
* BEWARE:
*
* The fact that you see your favorite vendor listed below does not
* imply that your equipment won't break when you use this software
* with it. It only means that the firmware of at least one device type
* of each vendor listed has been programmed successfully using this code.
*
* The -s option simulates a download but does nothing apart from that.
* It can be used to check what chunk sizes would have been used with the
* specified device.
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include <sys/types.h>
#include <sys/stat.h>
#include <err.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <cam/scsi/scsi_all.h>
#include <cam/scsi/scsi_message.h>
#include <camlib.h>
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
#include "progress.h"
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
#include "camcontrol.h"
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
#define WB_TIMEOUT 50000 /* 50 seconds */
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
typedef enum {
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
VENDOR_HGST,
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
VENDOR_HITACHI,
VENDOR_HP,
VENDOR_IBM,
VENDOR_PLEXTOR,
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
VENDOR_QUALSTAR,
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
VENDOR_QUANTUM,
Add firmware downloading support for Samsung drives Tested on Samsung SM1625 SSDs.
2013-09-06 16:34:09 +00:00
VENDOR_SAMSUNG,
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
VENDOR_SEAGATE,
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
VENDOR_SMART,
VENDOR_ATA,
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
VENDOR_UNKNOWN
} fw_vendor_t;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*
* FW_TUR_READY: The drive must return good status for a test unit ready.
*
* FW_TUR_NOT_READY: The drive must return not ready status for a test unit
* ready. You may want this in a removable media drive.
*
* FW_TUR_NA: It doesn't matter whether the drive is ready or not.
* This may be the case for a removable media drive.
*/
typedef enum {
FW_TUR_NONE,
FW_TUR_READY,
FW_TUR_NOT_READY,
FW_TUR_NA
} fw_tur_status;
/*
* FW_TIMEOUT_DEFAULT: Attempt to probe for a WRITE BUFFER timeout
* value from the drive. If we get an answer,
* use the Recommended timeout. Otherwise,
* use the default value from the table.
*
* FW_TIMEOUT_DEV_REPORTED: The timeout value was probed directly from
* the device.
*
* FW_TIMEOUT_NO_PROBE: Do not ask the device for a WRITE BUFFER
* timeout value. Use the device-specific
* value.
*
* FW_TIMEOUT_USER_SPEC: The user specified a timeout on the command
* line with the -t option. This overrides any
* probe or default timeout.
*/
typedef enum {
FW_TIMEOUT_DEFAULT,
FW_TIMEOUT_DEV_REPORTED,
FW_TIMEOUT_NO_PROBE,
FW_TIMEOUT_USER_SPEC
} fw_timeout_type;
/*
* type: Enumeration for the particular vendor.
*
* pattern: Pattern to match for the Vendor ID from the SCSI
* Inquiry data.
*
* dev_type: SCSI device type to match, or T_ANY to match any
* device from the given vendor. Note that if there
* is a specific device type listed for a particular
* vendor, it must be listed before a T_ANY entry.
*
* max_pkt_size: Maximum packet size when talking to a device. Note
* that although large data sizes may be supported by
* the target device, they may not be supported by the
* OS or the controller.
*
* cdb_byte2: This specifies byte 2 (byte 1 when counting from 0)
* of the CDB. This is generally the WRITE BUFFER mode.
*
* cdb_byte2_last: This specifies byte 2 for the last chunk of the
* download.
*
* inc_cdb_buffer_id: Increment the buffer ID by 1 for each chunk sent
* down to the drive.
*
* inc_cdb_offset: Increment the offset field in the CDB with the byte
* offset into the firmware file.
*
* tur_status: Pay attention to whether the device is ready before
* upgrading the firmware, or not. See above for the
* values.
*/
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
struct fw_vendor {
fw_vendor_t type;
const char *pattern;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
int dev_type;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
int max_pkt_size;
u_int8_t cdb_byte2;
u_int8_t cdb_byte2_last;
int inc_cdb_buffer_id;
int inc_cdb_offset;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
fw_tur_status tur_status;
int timeout_ms;
fw_timeout_type timeout_type;
};
/*
* Vendor notes:
*
* HGST: The packets need to be sent in multiples of 4K.
*
* IBM: For LTO and TS drives, the buffer ID is ignored in mode 7 (and
* some other modes). It treats the request as a firmware download.
* The offset (and therefore the length of each chunk sent) needs
* to be a multiple of the offset boundary specified for firmware
* (buffer ID 4) in the read buffer command. At least for LTO-6,
* that seems to be 0, but using a 32K chunk size should satisfy
* most any alignment requirement.
*
* SmrtStor: Mode 5 is also supported, but since the firmware is 400KB or
* so, we can't fit it in a single request in most cases.
*/
static struct fw_vendor vendors_list[] = {
{VENDOR_HGST, "HGST", T_DIRECT,
0x1000, 0x07, 0x07, 1, 0, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
{VENDOR_HITACHI, "HITACHI", T_ANY,
0x8000, 0x05, 0x05, 1, 0, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
{VENDOR_HP, "HP", T_ANY,
0x8000, 0x07, 0x07, 0, 1, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
{VENDOR_IBM, "IBM", T_SEQUENTIAL,
0x8000, 0x07, 0x07, 0, 1, FW_TUR_NA, 300 * 1000, FW_TIMEOUT_DEFAULT},
{VENDOR_IBM, "IBM", T_ANY,
0x8000, 0x05, 0x05, 1, 0, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
{VENDOR_PLEXTOR, "PLEXTOR", T_ANY,
0x2000, 0x04, 0x05, 0, 1, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
{VENDOR_QUALSTAR, "QUALSTAR", T_ANY,
0x2030, 0x05, 0x05, 0, 0, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
{VENDOR_QUANTUM, "QUANTUM", T_ANY,
0x2000, 0x04, 0x05, 0, 1, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
{VENDOR_SAMSUNG, "SAMSUNG", T_ANY,
0x8000, 0x07, 0x07, 0, 1, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
{VENDOR_SEAGATE, "SEAGATE", T_ANY,
0x8000, 0x07, 0x07, 0, 1, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
{VENDOR_SMART, "SmrtStor", T_DIRECT,
0x8000, 0x07, 0x07, 0, 1, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
Make WD and WDC aliases for HGST. HGST was bought by WDC. Over the years, it has sold different drives branded as HGST, WD or WDC. All of them need the HGST workaround of sending 4k-sized packets (or multiples of 4k). And the ones that don't really need this aren't broken by this change. Submitter is the vendor who has tested these changes on a number of drives. I've simplified it slightly, since we don't need additional vendors for this at this time. Submitted by: JacobBurley via github on behalf of WDC Pull Request: https://github.com/freebsd/freebsd/pull/391
2019-03-21 06:27:58 +00:00
{VENDOR_HGST, "WD", T_DIRECT,
0x1000, 0x07, 0x07, 1, 0, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
{VENDOR_HGST, "WDC", T_DIRECT,
0x1000, 0x07, 0x07, 1, 0, FW_TUR_READY, WB_TIMEOUT, FW_TIMEOUT_DEFAULT},
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*
* We match any ATA device. This is really just a placeholder,
* since we won't actually send a WRITE BUFFER with any of the
* listed parameters. If a SATA device is behind a SAS controller,
* the SCSI to ATA translation code (at least for LSI) doesn't
sbin: minor spelling fixes. No functional change.
2016-04-30 19:04:59 +00:00
* generally translate a SCSI WRITE BUFFER into an ATA DOWNLOAD
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
* MICROCODE command. So, we use the SCSI ATA PASS_THROUGH command
* to send the ATA DOWNLOAD MICROCODE command instead.
*/
{VENDOR_ATA, "ATA", T_ANY,
0x8000, 0x07, 0x07, 0, 1, FW_TUR_READY, WB_TIMEOUT,
FW_TIMEOUT_NO_PROBE},
{VENDOR_UNKNOWN, NULL, T_ANY,
0x0000, 0x00, 0x00, 0, 0, FW_TUR_NONE, WB_TIMEOUT, FW_TIMEOUT_DEFAULT}
};
struct fw_timeout_desc {
fw_timeout_type timeout_type;
const char *timeout_desc;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
};
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
static const struct fw_timeout_desc fw_timeout_desc_table[] = {
{ FW_TIMEOUT_DEFAULT, "the default" },
{ FW_TIMEOUT_DEV_REPORTED, "recommended by this particular device" },
{ FW_TIMEOUT_NO_PROBE, "the default" },
{ FW_TIMEOUT_USER_SPEC, "what was specified on the command line" }
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
};
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
#ifndef ATA_DOWNLOAD_MICROCODE
#define ATA_DOWNLOAD_MICROCODE 0x92
#endif
#define USE_OFFSETS_FEATURE 0x3
#ifndef LOW_SECTOR_SIZE
#define LOW_SECTOR_SIZE 512
#endif
#define ATA_MAKE_LBA(o, p) \
((((((o) / LOW_SECTOR_SIZE) >> 8) & 0xff) << 16) | \
((((o) / LOW_SECTOR_SIZE) & 0xff) << 8) | \
((((p) / LOW_SECTOR_SIZE) >> 8) & 0xff))
#define ATA_MAKE_SECTORS(p) (((p) / 512) & 0xff)
#ifndef UNKNOWN_MAX_PKT_SIZE
#define UNKNOWN_MAX_PKT_SIZE 0x8000
#endif
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
static struct fw_vendor *fw_get_vendor(struct cam_device *cam_dev,
struct ata_params *ident_buf);
static int fw_get_timeout(struct cam_device *cam_dev, struct fw_vendor *vp,
Add task attribute support to camcontrol(8). Users can use the new generic argument, -Q task_attr, to specify a task attribute (simple, ordered, head of queue, aca) for the commands issued. The the default is simple, which works with all SCSI devices that support tagged queueing. This will mostly be useful for debugging target behavior in certain situations. You can try it out by compiling CTL with CTL_IO_DELAY turned on (in sys/cam/ctl/ctl_io.h) and then do something like this with one of the CTL LUNs: ctladm delay 0:0 -l done -t 10 camcontrol tur da34 -v And at then before the 10 second timer is up, in another terminal: camcontrol inquiry da34 -Q ordered -v The Inquiry should complete just after the TUR completes. Ordinarily it would complete first because of the delay injection, but because the task attribute is set to ordered in this case, CTL holds it up until the previous command has completed. sbin/camcontrol/camcontrol.c: Add the new generic argument, -Q, which allows the user to specify a SCSI task attribute. The user can specify task attributes by name or numerically. Add a new task_attr arguments to SCSI sub-functions. sbin/camcontrol/attrib.c, sbin/camcontrol/camcontrol.h, sbin/camcontrol/fwdownload.c, sbin/camcontrol/modeedit.c, sbin/camcontrol/persist.c, sbin/camcontrol/timestamp.c, sbin/camcontrol/zone.c: Add the new task_attr argument to SCSI sub-functions. sbin/camcontrol/camcontrol.8: Document the new -Q option, and add an example. Sponsored by: Spectra Logic MFC after: 1 week
2017-02-17 20:04:22 +00:00
int task_attr, int retry_count, int timeout);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
static int fw_validate_ibm(struct cam_device *dev, int retry_count,
int timeout, int fd, char *buf,
const char *fw_img_path, int quiet);
static char *fw_read_img(struct cam_device *dev, int retry_count,
int timeout, int quiet, const char *fw_img_path,
struct fw_vendor *vp, int *num_bytes);
static int fw_check_device_ready(struct cam_device *dev,
camcontrol_devtype devtype,
struct fw_vendor *vp, int printerrors,
int timeout);
static int fw_download_img(struct cam_device *cam_dev,
struct fw_vendor *vp, char *buf, int img_size,
int sim_mode, int printerrors, int quiet,
int retry_count, int timeout, const char */*name*/,
camcontrol_devtype devtype);
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
/*
* Find entry in vendors list that belongs to
* the vendor of given cam device.
*/
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
static struct fw_vendor *
fw_get_vendor(struct cam_device *cam_dev, struct ata_params *ident_buf)
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
{
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
char vendor[42];
struct fw_vendor *vp;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
if (cam_dev == NULL)
return (NULL);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
if (ident_buf != NULL) {
cam_strvis((u_char *)vendor, ident_buf->model,
sizeof(ident_buf->model), sizeof(vendor));
for (vp = vendors_list; vp->pattern != NULL; vp++) {
if (vp->type == VENDOR_ATA)
return (vp);
}
} else {
cam_strvis((u_char *)vendor, (u_char *)cam_dev->inq_data.vendor,
sizeof(cam_dev->inq_data.vendor), sizeof(vendor));
}
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
for (vp = vendors_list; vp->pattern != NULL; vp++) {
if (!cam_strmatch((const u_char *)vendor,
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
(const u_char *)vp->pattern, strlen(vendor))) {
if ((vp->dev_type == T_ANY)
|| (vp->dev_type == SID_TYPE(&cam_dev->inq_data)))
break;
}
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
}
return (vp);
}
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
static int
fw_get_timeout(struct cam_device *cam_dev, struct fw_vendor *vp,
Add task attribute support to camcontrol(8). Users can use the new generic argument, -Q task_attr, to specify a task attribute (simple, ordered, head of queue, aca) for the commands issued. The the default is simple, which works with all SCSI devices that support tagged queueing. This will mostly be useful for debugging target behavior in certain situations. You can try it out by compiling CTL with CTL_IO_DELAY turned on (in sys/cam/ctl/ctl_io.h) and then do something like this with one of the CTL LUNs: ctladm delay 0:0 -l done -t 10 camcontrol tur da34 -v And at then before the 10 second timer is up, in another terminal: camcontrol inquiry da34 -Q ordered -v The Inquiry should complete just after the TUR completes. Ordinarily it would complete first because of the delay injection, but because the task attribute is set to ordered in this case, CTL holds it up until the previous command has completed. sbin/camcontrol/camcontrol.c: Add the new generic argument, -Q, which allows the user to specify a SCSI task attribute. The user can specify task attributes by name or numerically. Add a new task_attr arguments to SCSI sub-functions. sbin/camcontrol/attrib.c, sbin/camcontrol/camcontrol.h, sbin/camcontrol/fwdownload.c, sbin/camcontrol/modeedit.c, sbin/camcontrol/persist.c, sbin/camcontrol/timestamp.c, sbin/camcontrol/zone.c: Add the new task_attr argument to SCSI sub-functions. sbin/camcontrol/camcontrol.8: Document the new -Q option, and add an example. Sponsored by: Spectra Logic MFC after: 1 week
2017-02-17 20:04:22 +00:00
int task_attr, int retry_count, int timeout)
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
{
struct scsi_report_supported_opcodes_one *one;
struct scsi_report_supported_opcodes_timeout *td;
uint8_t *buf = NULL;
uint32_t fill_len = 0, cdb_len = 0, rec_timeout = 0;
int retval = 0;
/*
* If the user has specified a timeout on the command line, we let
* him override any default or probed value.
*/
if (timeout != 0) {
vp->timeout_type = FW_TIMEOUT_USER_SPEC;
vp->timeout_ms = timeout;
goto bailout;
}
/*
* Check to see whether we should probe for a timeout for this
* device.
*/
if (vp->timeout_type == FW_TIMEOUT_NO_PROBE)
goto bailout;
retval = scsigetopcodes(/*device*/ cam_dev,
/*opcode_set*/ 1,
/*opcode*/ WRITE_BUFFER,
/*show_sa_errors*/ 1,
/*sa_set*/ 0,
/*service_action*/ 0,
/*timeout_desc*/ 1,
Add task attribute support to camcontrol(8). Users can use the new generic argument, -Q task_attr, to specify a task attribute (simple, ordered, head of queue, aca) for the commands issued. The the default is simple, which works with all SCSI devices that support tagged queueing. This will mostly be useful for debugging target behavior in certain situations. You can try it out by compiling CTL with CTL_IO_DELAY turned on (in sys/cam/ctl/ctl_io.h) and then do something like this with one of the CTL LUNs: ctladm delay 0:0 -l done -t 10 camcontrol tur da34 -v And at then before the 10 second timer is up, in another terminal: camcontrol inquiry da34 -Q ordered -v The Inquiry should complete just after the TUR completes. Ordinarily it would complete first because of the delay injection, but because the task attribute is set to ordered in this case, CTL holds it up until the previous command has completed. sbin/camcontrol/camcontrol.c: Add the new generic argument, -Q, which allows the user to specify a SCSI task attribute. The user can specify task attributes by name or numerically. Add a new task_attr arguments to SCSI sub-functions. sbin/camcontrol/attrib.c, sbin/camcontrol/camcontrol.h, sbin/camcontrol/fwdownload.c, sbin/camcontrol/modeedit.c, sbin/camcontrol/persist.c, sbin/camcontrol/timestamp.c, sbin/camcontrol/zone.c: Add the new task_attr argument to SCSI sub-functions. sbin/camcontrol/camcontrol.8: Document the new -Q option, and add an example. Sponsored by: Spectra Logic MFC after: 1 week
2017-02-17 20:04:22 +00:00
/*task_attr*/ task_attr,
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*retry_count*/ retry_count,
/*timeout*/ 10000,
/*verbose*/ 0,
/*fill_len*/ &fill_len,
/*data_ptr*/ &buf);
/*
* It isn't an error if we can't get a timeout descriptor. We just
* continue on with the default timeout.
*/
if (retval != 0) {
retval = 0;
goto bailout;
}
/*
* Even if the drive didn't return a SCSI error, if we don't have
* enough data to contain the one opcode descriptor, the CDB
* structure and a timeout descriptor, we don't have the timeout
* value we're looking for. So we'll just fall back to the
* default value.
*/
if (fill_len < (sizeof(*one) + sizeof(struct scsi_write_buffer) +
sizeof(*td)))
goto bailout;
one = (struct scsi_report_supported_opcodes_one *)buf;
/*
* If the drive claims to not support the WRITE BUFFER command...
* fall back to the default timeout value and let things fail on
* the actual firmware download.
*/
if ((one->support & RSO_ONE_SUP_MASK) == RSO_ONE_SUP_NOT_SUP)
goto bailout;
cdb_len = scsi_2btoul(one->cdb_length);
td = (struct scsi_report_supported_opcodes_timeout *)
&buf[sizeof(*one) + cdb_len];
rec_timeout = scsi_4btoul(td->recommended_time);
/*
* If the recommended timeout is 0, then the device has probably
* returned a bogus value.
*/
if (rec_timeout == 0)
goto bailout;
/* CAM timeouts are in ms */
rec_timeout *= 1000;
vp->timeout_ms = rec_timeout;
vp->timeout_type = FW_TIMEOUT_DEV_REPORTED;
bailout:
return (retval);
}
#define SVPD_IBM_FW_DESIGNATION 0x03
/*
* IBM LTO and TS tape drives have an INQUIRY VPD page 0x3 with the following
* format:
*/
struct fw_ibm_tape_fw_designation {
uint8_t device;
uint8_t page_code;
uint8_t reserved;
uint8_t length;
uint8_t ascii_length;
uint8_t reserved2[3];
uint8_t load_id[4];
uint8_t fw_rev[4];
uint8_t ptf_number[4];
uint8_t patch_number[4];
uint8_t ru_name[8];
uint8_t lib_seq_num[5];
};
/*
* The firmware for IBM tape drives has the following header format. The
* load_id and ru_name in the header file should match what is returned in
* VPD page 0x3.
*/
struct fw_ibm_tape_fw_header {
uint8_t unspec[4];
uint8_t length[4]; /* Firmware and header! */
uint8_t load_id[4];
uint8_t fw_rev[4];
uint8_t reserved[8];
uint8_t ru_name[8];
};
static int
fw_validate_ibm(struct cam_device *dev, int retry_count, int timeout, int fd,
char *buf, const char *fw_img_path, int quiet)
{
union ccb *ccb;
struct fw_ibm_tape_fw_designation vpd_page;
struct fw_ibm_tape_fw_header *header;
char drive_rev[sizeof(vpd_page.fw_rev) + 1];
char file_rev[sizeof(vpd_page.fw_rev) + 1];
int retval = 1;
ccb = cam_getccb(dev);
if (ccb == NULL) {
warnx("couldn't allocate CCB");
goto bailout;
}
/* cam_getccb cleans up the header, caller has to zero the payload */
Fix multiple Coverity Out-of-bounds access false postive issues in CAM The currently used idiom for clearing the part of a ccb after its header generates one or two Coverity errors for each time it is used. All instances generate an Out-of-bounds access (ARRAY_VS_SINGLETON) error because of the treatment of the header as a two element array, with a pointer to the non-existent second element being passed as the starting address to bzero(). Some instances also alsp generate Out-of-bounds access (OVERRUN) errors, probably because the space being cleared is larger than the sizeofstruct ccb_hdr). In addition, this idiom is difficult for humans to understand and it is error prone. The user has to chose the proper struct ccb_* type (which does not appear in the surrounding code) for the sizeof() in the length calculation. I found several instances where the length was incorrect, which could cause either an actual out of bounds write, or incompletely clear the ccb. A better way is to write the code to clear the ccb itself starting at sizeof(ccb_hdr) bytes from the start of the ccb, and calculate the length based on the specific type of struct ccb_* being cleared as specified by the union ccb member being used. The latter can normally be seen in the nearby code. This is friendlier for Coverity and other static analysis tools because they will see that the intent is to clear the trailing part of the ccb. Wrap all of the boilerplate code in a convenient macro that only requires a pointer to the desired union ccb member (or a pointer to the union ccb itself) as an argument. Reported by: Coverity CID: 1007578, 1008684, 1009724, 1009773, 1011304, 1011306 CID: 1011307, 1011308, 1011309, 1011310, 1011311, 1011312 CID: 1011313, 1011314, 1011315, 1011316, 1011317, 1011318 CID: 1011319, 1011320, 1011321, 1011322, 1011324, 1011325 CID: 1011326, 1011327, 1011328, 1011329, 1011330, 1011374 CID: 1011390, 1011391, 1011392, 1011393, 1011394, 1011395 CID: 1011396, 1011397, 1011398, 1011399, 1011400, 1011401 CID: 1011402, 1011403, 1011404, 1011405, 1011406, 1011408 CID: 1011409, 1011410, 1011411, 1011412, 1011413, 1011414 CID: 1017461, 1018387, 1086860, 1086874, 1194257, 1229897 CID: 1229968, 1306229, 1306234, 1331282, 1331283, 1331294 CID: 1331295, 1331535, 1331536, 1331539, 1331540, 1341623 CID: 1341624, 1341637, 1341638, 1355264, 1355324 Reviewed by: scottl, ken, delphij, imp MFH: 1 month Differential Revision: https://reviews.freebsd.org/D6496
2016-05-24 00:57:11 +00:00
CCB_CLEAR_ALL_EXCEPT_HDR(&ccb->csio);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
bzero(&vpd_page, sizeof(vpd_page));
scsi_inquiry(&ccb->csio,
/*retries*/ retry_count,
/*cbfcnp*/ NULL,
/* tag_action */ MSG_SIMPLE_Q_TAG,
/* inq_buf */ (u_int8_t *)&vpd_page,
/* inq_len */ sizeof(vpd_page),
/* evpd */ 1,
/* page_code */ SVPD_IBM_FW_DESIGNATION,
/* sense_len */ SSD_FULL_SIZE,
/* timeout */ timeout ? timeout : 5000);
/* Disable freezing the device queue */
ccb->ccb_h.flags |= CAM_DEV_QFRZDIS;
if (retry_count != 0)
ccb->ccb_h.flags |= CAM_PASS_ERR_RECOVER;
if (cam_send_ccb(dev, ccb) < 0) {
warn("error getting firmware designation page");
cam_error_print(dev, ccb, CAM_ESF_ALL,
CAM_EPF_ALL, stderr);
cam_freeccb(ccb);
camcontrol(8): Fix another trivial double-free Reported by: Coverity CID: 1331222 Sponsored by: EMC / Isilon Storage Division
2016-05-11 22:25:14 +00:00
ccb = NULL;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
goto bailout;
}
if ((ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) {
cam_error_print(dev, ccb, CAM_ESF_ALL,
CAM_EPF_ALL, stderr);
goto bailout;
}
/*
* Read the firmware header only.
*/
if (read(fd, buf, sizeof(*header)) != sizeof(*header)) {
warn("unable to read %zu bytes from %s", sizeof(*header),
fw_img_path);
goto bailout;
}
/* Rewind the file back to 0 for the full file read. */
if (lseek(fd, 0, SEEK_SET) == -1) {
warn("Unable to lseek");
goto bailout;
}
header = (struct fw_ibm_tape_fw_header *)buf;
bzero(drive_rev, sizeof(drive_rev));
bcopy(vpd_page.fw_rev, drive_rev, sizeof(vpd_page.fw_rev));
bzero(file_rev, sizeof(file_rev));
bcopy(header->fw_rev, file_rev, sizeof(header->fw_rev));
if (quiet == 0) {
fprintf(stdout, "Current Drive Firmware version: %s\n",
drive_rev);
fprintf(stdout, "Firmware File version: %s\n", file_rev);
}
/*
* For IBM tape drives the load ID and RU name reported by the
* drive should match what is in the firmware file.
*/
if (bcmp(vpd_page.load_id, header->load_id,
MIN(sizeof(vpd_page.load_id), sizeof(header->load_id))) != 0) {
warnx("Drive Firmware load ID 0x%x does not match firmware "
"file load ID 0x%x", scsi_4btoul(vpd_page.load_id),
scsi_4btoul(header->load_id));
goto bailout;
}
if (bcmp(vpd_page.ru_name, header->ru_name,
MIN(sizeof(vpd_page.ru_name), sizeof(header->ru_name))) != 0) {
warnx("Drive Firmware RU name 0x%jx does not match firmware "
"file RU name 0x%jx",
(uintmax_t)scsi_8btou64(vpd_page.ru_name),
(uintmax_t)scsi_8btou64(header->ru_name));
goto bailout;
}
if (quiet == 0)
fprintf(stdout, "Firmware file is valid for this drive.\n");
retval = 0;
bailout:
Fix memory leaks in camcontrol Reported by: Coverity CID: 1331674, 1331675 Reviewed by: ken MFC after: 3 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D10588
2017-05-03 19:56:55 +00:00
cam_freeccb(ccb);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
return (retval);
}
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
/*
* Allocate a buffer and read fw image file into it
* from given path. Number of bytes read is stored
* in num_bytes.
*/
static char *
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
fw_read_img(struct cam_device *dev, int retry_count, int timeout, int quiet,
const char *fw_img_path, struct fw_vendor *vp, int *num_bytes)
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
{
int fd;
struct stat stbuf;
char *buf;
off_t img_size;
int skip_bytes = 0;
if ((fd = open(fw_img_path, O_RDONLY)) < 0) {
warn("Could not open image file %s", fw_img_path);
return (NULL);
}
if (fstat(fd, &stbuf) < 0) {
warn("Could not stat image file %s", fw_img_path);
goto bailout1;
}
if ((img_size = stbuf.st_size) == 0) {
warnx("Zero length image file %s", fw_img_path);
goto bailout1;
}
if ((buf = malloc(img_size)) == NULL) {
warnx("Could not allocate buffer to read image file %s",
fw_img_path);
goto bailout1;
}
/* Skip headers if applicable. */
switch (vp->type) {
case VENDOR_SEAGATE:
if (read(fd, buf, 16) != 16) {
warn("Could not read image file %s", fw_img_path);
goto bailout;
}
if (lseek(fd, 0, SEEK_SET) == -1) {
warn("Unable to lseek");
goto bailout;
}
if ((strncmp(buf, "SEAGATE,SEAGATE ", 16) == 0) ||
(img_size % 512 == 80))
skip_bytes = 80;
break;
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
case VENDOR_QUALSTAR:
skip_bytes = img_size % 1030;
break;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
case VENDOR_IBM: {
if (vp->dev_type != T_SEQUENTIAL)
break;
if (fw_validate_ibm(dev, retry_count, timeout, fd, buf,
fw_img_path, quiet) != 0)
goto bailout;
break;
}
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
default:
break;
}
if (skip_bytes != 0) {
fprintf(stdout, "Skipping %d byte header.\n", skip_bytes);
if (lseek(fd, skip_bytes, SEEK_SET) == -1) {
warn("Could not lseek");
goto bailout;
}
img_size -= skip_bytes;
}
/* Read image into a buffer. */
if (read(fd, buf, img_size) != img_size) {
warn("Could not read image file %s", fw_img_path);
goto bailout;
}
*num_bytes = img_size;
Fix resource leaks Found by: Coverity Scan, CID 1016673, 1007118 Approved by: re
2013-10-07 16:45:16 +00:00
close(fd);
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
return (buf);
bailout:
free(buf);
bailout1:
close(fd);
*num_bytes = 0;
return (NULL);
}
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*
* Returns 0 for "success", where success means that the device has met the
* requirement in the vendor structure for being ready or not ready when
* firmware is downloaded.
*
* Returns 1 for a failure to be ready to accept a firmware download.
* (e.g., a drive needs to be ready, but returns not ready)
*
* Returns -1 for any other failure.
*/
static int
fw_check_device_ready(struct cam_device *dev, camcontrol_devtype devtype,
struct fw_vendor *vp, int printerrors, int timeout)
{
union ccb *ccb;
int retval = 0;
int16_t *ptr = NULL;
size_t dxfer_len = 0;
if ((ccb = cam_getccb(dev)) == NULL) {
warnx("Could not allocate CCB");
retval = -1;
goto bailout;
}
Fix multiple Coverity Out-of-bounds access false postive issues in CAM The currently used idiom for clearing the part of a ccb after its header generates one or two Coverity errors for each time it is used. All instances generate an Out-of-bounds access (ARRAY_VS_SINGLETON) error because of the treatment of the header as a two element array, with a pointer to the non-existent second element being passed as the starting address to bzero(). Some instances also alsp generate Out-of-bounds access (OVERRUN) errors, probably because the space being cleared is larger than the sizeofstruct ccb_hdr). In addition, this idiom is difficult for humans to understand and it is error prone. The user has to chose the proper struct ccb_* type (which does not appear in the surrounding code) for the sizeof() in the length calculation. I found several instances where the length was incorrect, which could cause either an actual out of bounds write, or incompletely clear the ccb. A better way is to write the code to clear the ccb itself starting at sizeof(ccb_hdr) bytes from the start of the ccb, and calculate the length based on the specific type of struct ccb_* being cleared as specified by the union ccb member being used. The latter can normally be seen in the nearby code. This is friendlier for Coverity and other static analysis tools because they will see that the intent is to clear the trailing part of the ccb. Wrap all of the boilerplate code in a convenient macro that only requires a pointer to the desired union ccb member (or a pointer to the union ccb itself) as an argument. Reported by: Coverity CID: 1007578, 1008684, 1009724, 1009773, 1011304, 1011306 CID: 1011307, 1011308, 1011309, 1011310, 1011311, 1011312 CID: 1011313, 1011314, 1011315, 1011316, 1011317, 1011318 CID: 1011319, 1011320, 1011321, 1011322, 1011324, 1011325 CID: 1011326, 1011327, 1011328, 1011329, 1011330, 1011374 CID: 1011390, 1011391, 1011392, 1011393, 1011394, 1011395 CID: 1011396, 1011397, 1011398, 1011399, 1011400, 1011401 CID: 1011402, 1011403, 1011404, 1011405, 1011406, 1011408 CID: 1011409, 1011410, 1011411, 1011412, 1011413, 1011414 CID: 1017461, 1018387, 1086860, 1086874, 1194257, 1229897 CID: 1229968, 1306229, 1306234, 1331282, 1331283, 1331294 CID: 1331295, 1331535, 1331536, 1331539, 1331540, 1341623 CID: 1341624, 1341637, 1341638, 1355264, 1355324 Reviewed by: scottl, ken, delphij, imp MFH: 1 month Differential Revision: https://reviews.freebsd.org/D6496
2016-05-24 00:57:11 +00:00
CCB_CLEAR_ALL_EXCEPT_HDR(ccb);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
if (devtype != CC_DT_SCSI) {
dxfer_len = sizeof(struct ata_params);
ptr = (uint16_t *)malloc(dxfer_len);
if (ptr == NULL) {
warnx("can't malloc memory for identify");
retval = -1;
goto bailout;
}
bzero(ptr, dxfer_len);
}
switch (devtype) {
case CC_DT_SCSI:
scsi_test_unit_ready(&ccb->csio,
/*retries*/ 0,
/*cbfcnp*/ NULL,
/*tag_action*/ MSG_SIMPLE_Q_TAG,
/*sense_len*/ SSD_FULL_SIZE,
/*timeout*/ 5000);
break;
Use the more proper term of SATL instead of ATA_BEHIND_SCSI. Most people know SAS attached SATA devices by the name SAT or SATL (with the latter being a little more common). Change the device type ATA_BEHIND_SCSI to SATL since it's more specific and meaningful. Suggested by: scottl@
2019-07-15 20:25:41 +00:00
case CC_DT_SATL:
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
case CC_DT_ATA: {
Add support for managing Shingled Magnetic Recording (SMR) drives. This change includes support for SCSI SMR drives (which conform to the Zoned Block Commands or ZBC spec) and ATA SMR drives (which conform to the Zoned ATA Command Set or ZAC spec) behind SAS expanders. This includes full management support through the GEOM BIO interface, and through a new userland utility, zonectl(8), and through camcontrol(8). This is now ready for filesystems to use to detect and manage zoned drives. (There is no work in progress that I know of to use this for ZFS or UFS, if anyone is interested, let me know and I may have some suggestions.) Also, improve ATA command passthrough and dispatch support, both via ATA and ATA passthrough over SCSI. Also, add support to camcontrol(8) for the ATA Extended Power Conditions feature set. You can now manage ATA device power states, and set various idle time thresholds for a drive to enter lower power states. Note that this change cannot be MFCed in full, because it depends on changes to the struct bio API that break compatilibity. In order to avoid breaking the stable API, only changes that don't touch or depend on the struct bio changes can be merged. For example, the camcontrol(8) changes don't depend on the new bio API, but zonectl(8) and the probe changes to the da(4) and ada(4) drivers do depend on it. Also note that the SMR changes have not yet been tested with an actual SCSI ZBC device, or a SCSI to ATA translation layer (SAT) that supports ZBC to ZAC translation. I have not yet gotten a suitable drive or SAT layer, so any testing help would be appreciated. These changes have been tested with Seagate Host Aware SATA drives attached to both SAS and SATA controllers. Also, I do not have any SATA Host Managed devices, and I suspect that it may take additional (hopefully minor) changes to support them. Thanks to Seagate for supplying the test hardware and answering questions. sbin/camcontrol/Makefile: Add epc.c and zone.c. sbin/camcontrol/camcontrol.8: Document the zone and epc subcommands. sbin/camcontrol/camcontrol.c: Add the zone and epc subcommands. Add auxiliary register support to build_ata_cmd(). Make sure to set the CAM_ATAIO_NEEDRESULT, CAM_ATAIO_DMA, and CAM_ATAIO_FPDMA flags as appropriate for ATA commands. Add a new get_ata_status() function to parse ATA result from SCSI sense descriptors (for ATA passthrough over SCSI) and ATA I/O requests. sbin/camcontrol/camcontrol.h: Update the build_ata_cmd() prototype Add get_ata_status(), zone(), and epc(). sbin/camcontrol/epc.c: Support for ATA Extended Power Conditions features. This includes support for all features documented in the ACS-4 Revision 12 specification from t13.org (dated February 18, 2016). The EPC feature set allows putting a drive into a power power mode immediately, or setting timeouts so that the drive will automatically enter progressively lower power states after various idle times. sbin/camcontrol/fwdownload.c: Update the firmware download code for the new build_ata_cmd() arguments. sbin/camcontrol/zone.c: Implement support for Shingled Magnetic Recording (SMR) drives via SCSI Zoned Block Commands (ZBC) and ATA Zoned Device ATA Command Set (ZAC). These specs were developed in concert, and are functionally identical. The primary differences are due to SCSI and ATA differences. (SCSI is big endian, ATA is little endian, for example.) This includes support for all commands defined in the ZBC and ZAC specs. sys/cam/ata/ata_all.c: Decode a number of additional ATA command names in ata_op_string(). Add a new CCB building function, ata_read_log(). Add ata_zac_mgmt_in() and ata_zac_mgmt_out() CCB building functions. These support both DMA and NCQ encapsulation. sys/cam/ata/ata_all.h: Add prototypes for ata_read_log(), ata_zac_mgmt_out(), and ata_zac_mgmt_in(). sys/cam/ata/ata_da.c: Revamp the ada(4) driver to support zoned devices. Add four new probe states to gather information needed for zone support. Add a new adasetflags() function to avoid duplication of large blocks of flag setting between the async handler and register functions. Add new sysctl variables that describe zone support and paramters. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. sys/cam/scsi/scsi_all.c: Add command descriptions for the ZBC IN/OUT commands. Add descriptions for ZBC Host Managed devices. Add a new function, scsi_ata_pass() to do ATA passthrough over SCSI. This will eventually replace scsi_ata_pass_16() -- it can create the 12, 16, and 32-byte variants of the ATA PASS-THROUGH command, and supports setting all of the registers defined as of SAT-4, Revision 5 (March 11, 2016). Change scsi_ata_identify() to use scsi_ata_pass() instead of scsi_ata_pass_16(). Add a new scsi_ata_read_log() function to facilitate reading ATA logs via SCSI. sys/cam/scsi/scsi_all.h: Add the new ATA PASS-THROUGH(32) command CDB. Add extended and variable CDB opcodes. Add Zoned Block Device Characteristics VPD page. Add ATA Return SCSI sense descriptor. Add prototypes for scsi_ata_read_log() and scsi_ata_pass(). sys/cam/scsi/scsi_da.c: Revamp the da(4) driver to support zoned devices. Add five new probe states, four of which are needed for ATA devices. Add five new sysctl variables that describe zone support and parameters. The da(4) driver supports SCSI ZBC devices, as well as ATA ZAC devices when they are attached via a SCSI to ATA Translation (SAT) layer. Since ZBC -> ZAC translation is a new feature in the T10 SAT-4 spec, most SATA drives will be supported via ATA commands sent via the SCSI ATA PASS-THROUGH command. The da(4) driver will prefer the ZBC interface, if it is available, for performance reasons, but will use the ATA PASS-THROUGH interface to the ZAC command set if the SAT layer doesn't support translation yet. As I mentioned above, ZBC command support is untested. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. Add scsi_zbc_in() and scsi_zbc_out() CCB building functions. Add scsi_ata_zac_mgmt_out() and scsi_ata_zac_mgmt_in() CCB/CDB building functions. Note that these have return values, unlike almost all other CCB building functions in CAM. The reason is that they can fail, depending upon the particular combination of input parameters. The primary failure case is if the user wants NCQ, but fails to specify additional CDB storage. NCQ requires using the 32-byte version of the SCSI ATA PASS-THROUGH command, and the current CAM CDB size is 16 bytes. sys/cam/scsi/scsi_da.h: Add ZBC IN and ZBC OUT CDBs and opcodes. Add SCSI Report Zones data structures. Add scsi_zbc_in(), scsi_zbc_out(), scsi_ata_zac_mgmt_out(), and scsi_ata_zac_mgmt_in() prototypes. sys/dev/ahci/ahci.c: Fix SEND / RECEIVE FPDMA QUEUED in the ahci(4) driver. ahci_setup_fis() previously set the top bits of the sector count register in the FIS to 0 for FPDMA commands. This is okay for read and write, because the PRIO field is in the only thing in those bits, and we don't implement that further up the stack. But, for SEND and RECEIVE FPDMA QUEUED, the subcommand is in that byte, so it needs to be transmitted to the drive. In ahci_setup_fis(), always set the the top 8 bits of the sector count register. We need it in both the standard and NCQ / FPDMA cases. sys/geom/eli/g_eli.c: Pass BIO_ZONE commands through the GELI class. sys/geom/geom.h: Add g_io_zonecmd() prototype. sys/geom/geom_dev.c: Add new DIOCZONECMD ioctl, which allows sending zone commands to disks. sys/geom/geom_disk.c: Add support for BIO_ZONE commands. sys/geom/geom_disk.h: Add a new flag, DISKFLAG_CANZONE, that indicates that a given GEOM disk client can handle BIO_ZONE commands. sys/geom/geom_io.c: Add a new function, g_io_zonecmd(), that handles execution of BIO_ZONE commands. Add permissions check for BIO_ZONE commands. Add command decoding for BIO_ZONE commands. sys/geom/geom_subr.c: Add DDB command decoding for BIO_ZONE commands. sys/kern/subr_devstat.c: Record statistics for REPORT ZONES commands. Note that the number of bytes transferred for REPORT ZONES won't quite match what is received from the harware. This is because we're necessarily counting bytes coming from the da(4) / ada(4) drivers, which are using the disk_zone.h interface to communicate up the stack. The structure sizes it uses are slightly different than the SCSI and ATA structure sizes. sys/sys/ata.h: Add many bit and structure definitions for ZAC, NCQ, and EPC command support. sys/sys/bio.h: Convert the bio_cmd field to a straight enumeration. This will yield more space for additional commands in the future. After change r297955 and other related changes, this is now possible. Converting to an enumeration will also prevent use as a bitmask in the future. sys/sys/disk.h: Define the DIOCZONECMD ioctl. sys/sys/disk_zone.h: Add a new API for managing zoned disks. This is very close to the SCSI ZBC and ATA ZAC standards, but uses integers in native byte order instead of big endian (SCSI) or little endian (ATA) byte arrays. This is intended to offer to the complete feature set of the ZBC and ZAC disk management without requiring the application developer to include SCSI or ATA headers. We also use one set of headers for ioctl consumers and kernel bio-level consumers. sys/sys/param.h: Bump __FreeBSD_version for sys/bio.h command changes, and inclusion of SMR support. usr.sbin/Makefile: Add the zonectl utility. usr.sbin/diskinfo/diskinfo.c Add disk zoning capability to the 'diskinfo -v' output. usr.sbin/zonectl/Makefile: Add zonectl makefile. usr.sbin/zonectl/zonectl.8 zonectl(8) man page. usr.sbin/zonectl/zonectl.c The zonectl(8) utility. This allows managing SCSI or ATA zoned disks via the disk_zone.h API. You can report zones, reset write pointers, get parameters, etc. Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D6147 Reviewed by: wblock (documentation)
2016-05-19 14:08:36 +00:00
retval = build_ata_cmd(ccb,
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*retries*/ 1,
/*flags*/ CAM_DIR_IN,
/*tag_action*/ MSG_SIMPLE_Q_TAG,
/*protocol*/ AP_PROTO_PIO_IN,
Supply SAT layer with valid transfer sizes. This is a rework of r344701, that noticed that number of bytes passes to 8 bit sector count field gets truncated. First decision was to not pass anything, since ATA specs define the field as N/A. But it appeared to be a problem for some SAT devices, that require information about data transfer to operate properly. Some additional investigation shown that it is quite a common practice to set unused fields of ATA commands (fortunately ATA specs formally allow it) to supply the information to SAT layer. I have found SAS-SATA interposer that does not allow pass-through without it. As side effect, reduce code duplication by removing ata_do_28bit_cmd() function, replacing it with more universal ata_do_cmd(). MFC after: 1 week Sponsored by: iXsystems, Inc.
2019-09-07 15:56:00 +00:00
/*ata_flags*/ AP_FLAG_BYT_BLOK_BLOCKS |
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
AP_FLAG_TLEN_SECT_CNT |
AP_FLAG_TDIR_FROM_DEV,
/*features*/ 0,
Supply SAT layer with valid transfer sizes. This is a rework of r344701, that noticed that number of bytes passes to 8 bit sector count field gets truncated. First decision was to not pass anything, since ATA specs define the field as N/A. But it appeared to be a problem for some SAT devices, that require information about data transfer to operate properly. Some additional investigation shown that it is quite a common practice to set unused fields of ATA commands (fortunately ATA specs formally allow it) to supply the information to SAT layer. I have found SAS-SATA interposer that does not allow pass-through without it. As side effect, reduce code duplication by removing ata_do_28bit_cmd() function, replacing it with more universal ata_do_cmd(). MFC after: 1 week Sponsored by: iXsystems, Inc.
2019-09-07 15:56:00 +00:00
/*sector_count*/ dxfer_len / 512,
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*lba*/ 0,
/*command*/ ATA_ATA_IDENTIFY,
Add support for managing Shingled Magnetic Recording (SMR) drives. This change includes support for SCSI SMR drives (which conform to the Zoned Block Commands or ZBC spec) and ATA SMR drives (which conform to the Zoned ATA Command Set or ZAC spec) behind SAS expanders. This includes full management support through the GEOM BIO interface, and through a new userland utility, zonectl(8), and through camcontrol(8). This is now ready for filesystems to use to detect and manage zoned drives. (There is no work in progress that I know of to use this for ZFS or UFS, if anyone is interested, let me know and I may have some suggestions.) Also, improve ATA command passthrough and dispatch support, both via ATA and ATA passthrough over SCSI. Also, add support to camcontrol(8) for the ATA Extended Power Conditions feature set. You can now manage ATA device power states, and set various idle time thresholds for a drive to enter lower power states. Note that this change cannot be MFCed in full, because it depends on changes to the struct bio API that break compatilibity. In order to avoid breaking the stable API, only changes that don't touch or depend on the struct bio changes can be merged. For example, the camcontrol(8) changes don't depend on the new bio API, but zonectl(8) and the probe changes to the da(4) and ada(4) drivers do depend on it. Also note that the SMR changes have not yet been tested with an actual SCSI ZBC device, or a SCSI to ATA translation layer (SAT) that supports ZBC to ZAC translation. I have not yet gotten a suitable drive or SAT layer, so any testing help would be appreciated. These changes have been tested with Seagate Host Aware SATA drives attached to both SAS and SATA controllers. Also, I do not have any SATA Host Managed devices, and I suspect that it may take additional (hopefully minor) changes to support them. Thanks to Seagate for supplying the test hardware and answering questions. sbin/camcontrol/Makefile: Add epc.c and zone.c. sbin/camcontrol/camcontrol.8: Document the zone and epc subcommands. sbin/camcontrol/camcontrol.c: Add the zone and epc subcommands. Add auxiliary register support to build_ata_cmd(). Make sure to set the CAM_ATAIO_NEEDRESULT, CAM_ATAIO_DMA, and CAM_ATAIO_FPDMA flags as appropriate for ATA commands. Add a new get_ata_status() function to parse ATA result from SCSI sense descriptors (for ATA passthrough over SCSI) and ATA I/O requests. sbin/camcontrol/camcontrol.h: Update the build_ata_cmd() prototype Add get_ata_status(), zone(), and epc(). sbin/camcontrol/epc.c: Support for ATA Extended Power Conditions features. This includes support for all features documented in the ACS-4 Revision 12 specification from t13.org (dated February 18, 2016). The EPC feature set allows putting a drive into a power power mode immediately, or setting timeouts so that the drive will automatically enter progressively lower power states after various idle times. sbin/camcontrol/fwdownload.c: Update the firmware download code for the new build_ata_cmd() arguments. sbin/camcontrol/zone.c: Implement support for Shingled Magnetic Recording (SMR) drives via SCSI Zoned Block Commands (ZBC) and ATA Zoned Device ATA Command Set (ZAC). These specs were developed in concert, and are functionally identical. The primary differences are due to SCSI and ATA differences. (SCSI is big endian, ATA is little endian, for example.) This includes support for all commands defined in the ZBC and ZAC specs. sys/cam/ata/ata_all.c: Decode a number of additional ATA command names in ata_op_string(). Add a new CCB building function, ata_read_log(). Add ata_zac_mgmt_in() and ata_zac_mgmt_out() CCB building functions. These support both DMA and NCQ encapsulation. sys/cam/ata/ata_all.h: Add prototypes for ata_read_log(), ata_zac_mgmt_out(), and ata_zac_mgmt_in(). sys/cam/ata/ata_da.c: Revamp the ada(4) driver to support zoned devices. Add four new probe states to gather information needed for zone support. Add a new adasetflags() function to avoid duplication of large blocks of flag setting between the async handler and register functions. Add new sysctl variables that describe zone support and paramters. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. sys/cam/scsi/scsi_all.c: Add command descriptions for the ZBC IN/OUT commands. Add descriptions for ZBC Host Managed devices. Add a new function, scsi_ata_pass() to do ATA passthrough over SCSI. This will eventually replace scsi_ata_pass_16() -- it can create the 12, 16, and 32-byte variants of the ATA PASS-THROUGH command, and supports setting all of the registers defined as of SAT-4, Revision 5 (March 11, 2016). Change scsi_ata_identify() to use scsi_ata_pass() instead of scsi_ata_pass_16(). Add a new scsi_ata_read_log() function to facilitate reading ATA logs via SCSI. sys/cam/scsi/scsi_all.h: Add the new ATA PASS-THROUGH(32) command CDB. Add extended and variable CDB opcodes. Add Zoned Block Device Characteristics VPD page. Add ATA Return SCSI sense descriptor. Add prototypes for scsi_ata_read_log() and scsi_ata_pass(). sys/cam/scsi/scsi_da.c: Revamp the da(4) driver to support zoned devices. Add five new probe states, four of which are needed for ATA devices. Add five new sysctl variables that describe zone support and parameters. The da(4) driver supports SCSI ZBC devices, as well as ATA ZAC devices when they are attached via a SCSI to ATA Translation (SAT) layer. Since ZBC -> ZAC translation is a new feature in the T10 SAT-4 spec, most SATA drives will be supported via ATA commands sent via the SCSI ATA PASS-THROUGH command. The da(4) driver will prefer the ZBC interface, if it is available, for performance reasons, but will use the ATA PASS-THROUGH interface to the ZAC command set if the SAT layer doesn't support translation yet. As I mentioned above, ZBC command support is untested. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. Add scsi_zbc_in() and scsi_zbc_out() CCB building functions. Add scsi_ata_zac_mgmt_out() and scsi_ata_zac_mgmt_in() CCB/CDB building functions. Note that these have return values, unlike almost all other CCB building functions in CAM. The reason is that they can fail, depending upon the particular combination of input parameters. The primary failure case is if the user wants NCQ, but fails to specify additional CDB storage. NCQ requires using the 32-byte version of the SCSI ATA PASS-THROUGH command, and the current CAM CDB size is 16 bytes. sys/cam/scsi/scsi_da.h: Add ZBC IN and ZBC OUT CDBs and opcodes. Add SCSI Report Zones data structures. Add scsi_zbc_in(), scsi_zbc_out(), scsi_ata_zac_mgmt_out(), and scsi_ata_zac_mgmt_in() prototypes. sys/dev/ahci/ahci.c: Fix SEND / RECEIVE FPDMA QUEUED in the ahci(4) driver. ahci_setup_fis() previously set the top bits of the sector count register in the FIS to 0 for FPDMA commands. This is okay for read and write, because the PRIO field is in the only thing in those bits, and we don't implement that further up the stack. But, for SEND and RECEIVE FPDMA QUEUED, the subcommand is in that byte, so it needs to be transmitted to the drive. In ahci_setup_fis(), always set the the top 8 bits of the sector count register. We need it in both the standard and NCQ / FPDMA cases. sys/geom/eli/g_eli.c: Pass BIO_ZONE commands through the GELI class. sys/geom/geom.h: Add g_io_zonecmd() prototype. sys/geom/geom_dev.c: Add new DIOCZONECMD ioctl, which allows sending zone commands to disks. sys/geom/geom_disk.c: Add support for BIO_ZONE commands. sys/geom/geom_disk.h: Add a new flag, DISKFLAG_CANZONE, that indicates that a given GEOM disk client can handle BIO_ZONE commands. sys/geom/geom_io.c: Add a new function, g_io_zonecmd(), that handles execution of BIO_ZONE commands. Add permissions check for BIO_ZONE commands. Add command decoding for BIO_ZONE commands. sys/geom/geom_subr.c: Add DDB command decoding for BIO_ZONE commands. sys/kern/subr_devstat.c: Record statistics for REPORT ZONES commands. Note that the number of bytes transferred for REPORT ZONES won't quite match what is received from the harware. This is because we're necessarily counting bytes coming from the da(4) / ada(4) drivers, which are using the disk_zone.h interface to communicate up the stack. The structure sizes it uses are slightly different than the SCSI and ATA structure sizes. sys/sys/ata.h: Add many bit and structure definitions for ZAC, NCQ, and EPC command support. sys/sys/bio.h: Convert the bio_cmd field to a straight enumeration. This will yield more space for additional commands in the future. After change r297955 and other related changes, this is now possible. Converting to an enumeration will also prevent use as a bitmask in the future. sys/sys/disk.h: Define the DIOCZONECMD ioctl. sys/sys/disk_zone.h: Add a new API for managing zoned disks. This is very close to the SCSI ZBC and ATA ZAC standards, but uses integers in native byte order instead of big endian (SCSI) or little endian (ATA) byte arrays. This is intended to offer to the complete feature set of the ZBC and ZAC disk management without requiring the application developer to include SCSI or ATA headers. We also use one set of headers for ioctl consumers and kernel bio-level consumers. sys/sys/param.h: Bump __FreeBSD_version for sys/bio.h command changes, and inclusion of SMR support. usr.sbin/Makefile: Add the zonectl utility. usr.sbin/diskinfo/diskinfo.c Add disk zoning capability to the 'diskinfo -v' output. usr.sbin/zonectl/Makefile: Add zonectl makefile. usr.sbin/zonectl/zonectl.8 zonectl(8) man page. usr.sbin/zonectl/zonectl.c The zonectl(8) utility. This allows managing SCSI or ATA zoned disks via the disk_zone.h API. You can report zones, reset write pointers, get parameters, etc. Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D6147 Reviewed by: wblock (documentation)
2016-05-19 14:08:36 +00:00
/*auxiliary*/ 0,
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*data_ptr*/ (uint8_t *)ptr,
/*dxfer_len*/ dxfer_len,
Add support for managing Shingled Magnetic Recording (SMR) drives. This change includes support for SCSI SMR drives (which conform to the Zoned Block Commands or ZBC spec) and ATA SMR drives (which conform to the Zoned ATA Command Set or ZAC spec) behind SAS expanders. This includes full management support through the GEOM BIO interface, and through a new userland utility, zonectl(8), and through camcontrol(8). This is now ready for filesystems to use to detect and manage zoned drives. (There is no work in progress that I know of to use this for ZFS or UFS, if anyone is interested, let me know and I may have some suggestions.) Also, improve ATA command passthrough and dispatch support, both via ATA and ATA passthrough over SCSI. Also, add support to camcontrol(8) for the ATA Extended Power Conditions feature set. You can now manage ATA device power states, and set various idle time thresholds for a drive to enter lower power states. Note that this change cannot be MFCed in full, because it depends on changes to the struct bio API that break compatilibity. In order to avoid breaking the stable API, only changes that don't touch or depend on the struct bio changes can be merged. For example, the camcontrol(8) changes don't depend on the new bio API, but zonectl(8) and the probe changes to the da(4) and ada(4) drivers do depend on it. Also note that the SMR changes have not yet been tested with an actual SCSI ZBC device, or a SCSI to ATA translation layer (SAT) that supports ZBC to ZAC translation. I have not yet gotten a suitable drive or SAT layer, so any testing help would be appreciated. These changes have been tested with Seagate Host Aware SATA drives attached to both SAS and SATA controllers. Also, I do not have any SATA Host Managed devices, and I suspect that it may take additional (hopefully minor) changes to support them. Thanks to Seagate for supplying the test hardware and answering questions. sbin/camcontrol/Makefile: Add epc.c and zone.c. sbin/camcontrol/camcontrol.8: Document the zone and epc subcommands. sbin/camcontrol/camcontrol.c: Add the zone and epc subcommands. Add auxiliary register support to build_ata_cmd(). Make sure to set the CAM_ATAIO_NEEDRESULT, CAM_ATAIO_DMA, and CAM_ATAIO_FPDMA flags as appropriate for ATA commands. Add a new get_ata_status() function to parse ATA result from SCSI sense descriptors (for ATA passthrough over SCSI) and ATA I/O requests. sbin/camcontrol/camcontrol.h: Update the build_ata_cmd() prototype Add get_ata_status(), zone(), and epc(). sbin/camcontrol/epc.c: Support for ATA Extended Power Conditions features. This includes support for all features documented in the ACS-4 Revision 12 specification from t13.org (dated February 18, 2016). The EPC feature set allows putting a drive into a power power mode immediately, or setting timeouts so that the drive will automatically enter progressively lower power states after various idle times. sbin/camcontrol/fwdownload.c: Update the firmware download code for the new build_ata_cmd() arguments. sbin/camcontrol/zone.c: Implement support for Shingled Magnetic Recording (SMR) drives via SCSI Zoned Block Commands (ZBC) and ATA Zoned Device ATA Command Set (ZAC). These specs were developed in concert, and are functionally identical. The primary differences are due to SCSI and ATA differences. (SCSI is big endian, ATA is little endian, for example.) This includes support for all commands defined in the ZBC and ZAC specs. sys/cam/ata/ata_all.c: Decode a number of additional ATA command names in ata_op_string(). Add a new CCB building function, ata_read_log(). Add ata_zac_mgmt_in() and ata_zac_mgmt_out() CCB building functions. These support both DMA and NCQ encapsulation. sys/cam/ata/ata_all.h: Add prototypes for ata_read_log(), ata_zac_mgmt_out(), and ata_zac_mgmt_in(). sys/cam/ata/ata_da.c: Revamp the ada(4) driver to support zoned devices. Add four new probe states to gather information needed for zone support. Add a new adasetflags() function to avoid duplication of large blocks of flag setting between the async handler and register functions. Add new sysctl variables that describe zone support and paramters. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. sys/cam/scsi/scsi_all.c: Add command descriptions for the ZBC IN/OUT commands. Add descriptions for ZBC Host Managed devices. Add a new function, scsi_ata_pass() to do ATA passthrough over SCSI. This will eventually replace scsi_ata_pass_16() -- it can create the 12, 16, and 32-byte variants of the ATA PASS-THROUGH command, and supports setting all of the registers defined as of SAT-4, Revision 5 (March 11, 2016). Change scsi_ata_identify() to use scsi_ata_pass() instead of scsi_ata_pass_16(). Add a new scsi_ata_read_log() function to facilitate reading ATA logs via SCSI. sys/cam/scsi/scsi_all.h: Add the new ATA PASS-THROUGH(32) command CDB. Add extended and variable CDB opcodes. Add Zoned Block Device Characteristics VPD page. Add ATA Return SCSI sense descriptor. Add prototypes for scsi_ata_read_log() and scsi_ata_pass(). sys/cam/scsi/scsi_da.c: Revamp the da(4) driver to support zoned devices. Add five new probe states, four of which are needed for ATA devices. Add five new sysctl variables that describe zone support and parameters. The da(4) driver supports SCSI ZBC devices, as well as ATA ZAC devices when they are attached via a SCSI to ATA Translation (SAT) layer. Since ZBC -> ZAC translation is a new feature in the T10 SAT-4 spec, most SATA drives will be supported via ATA commands sent via the SCSI ATA PASS-THROUGH command. The da(4) driver will prefer the ZBC interface, if it is available, for performance reasons, but will use the ATA PASS-THROUGH interface to the ZAC command set if the SAT layer doesn't support translation yet. As I mentioned above, ZBC command support is untested. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. Add scsi_zbc_in() and scsi_zbc_out() CCB building functions. Add scsi_ata_zac_mgmt_out() and scsi_ata_zac_mgmt_in() CCB/CDB building functions. Note that these have return values, unlike almost all other CCB building functions in CAM. The reason is that they can fail, depending upon the particular combination of input parameters. The primary failure case is if the user wants NCQ, but fails to specify additional CDB storage. NCQ requires using the 32-byte version of the SCSI ATA PASS-THROUGH command, and the current CAM CDB size is 16 bytes. sys/cam/scsi/scsi_da.h: Add ZBC IN and ZBC OUT CDBs and opcodes. Add SCSI Report Zones data structures. Add scsi_zbc_in(), scsi_zbc_out(), scsi_ata_zac_mgmt_out(), and scsi_ata_zac_mgmt_in() prototypes. sys/dev/ahci/ahci.c: Fix SEND / RECEIVE FPDMA QUEUED in the ahci(4) driver. ahci_setup_fis() previously set the top bits of the sector count register in the FIS to 0 for FPDMA commands. This is okay for read and write, because the PRIO field is in the only thing in those bits, and we don't implement that further up the stack. But, for SEND and RECEIVE FPDMA QUEUED, the subcommand is in that byte, so it needs to be transmitted to the drive. In ahci_setup_fis(), always set the the top 8 bits of the sector count register. We need it in both the standard and NCQ / FPDMA cases. sys/geom/eli/g_eli.c: Pass BIO_ZONE commands through the GELI class. sys/geom/geom.h: Add g_io_zonecmd() prototype. sys/geom/geom_dev.c: Add new DIOCZONECMD ioctl, which allows sending zone commands to disks. sys/geom/geom_disk.c: Add support for BIO_ZONE commands. sys/geom/geom_disk.h: Add a new flag, DISKFLAG_CANZONE, that indicates that a given GEOM disk client can handle BIO_ZONE commands. sys/geom/geom_io.c: Add a new function, g_io_zonecmd(), that handles execution of BIO_ZONE commands. Add permissions check for BIO_ZONE commands. Add command decoding for BIO_ZONE commands. sys/geom/geom_subr.c: Add DDB command decoding for BIO_ZONE commands. sys/kern/subr_devstat.c: Record statistics for REPORT ZONES commands. Note that the number of bytes transferred for REPORT ZONES won't quite match what is received from the harware. This is because we're necessarily counting bytes coming from the da(4) / ada(4) drivers, which are using the disk_zone.h interface to communicate up the stack. The structure sizes it uses are slightly different than the SCSI and ATA structure sizes. sys/sys/ata.h: Add many bit and structure definitions for ZAC, NCQ, and EPC command support. sys/sys/bio.h: Convert the bio_cmd field to a straight enumeration. This will yield more space for additional commands in the future. After change r297955 and other related changes, this is now possible. Converting to an enumeration will also prevent use as a bitmask in the future. sys/sys/disk.h: Define the DIOCZONECMD ioctl. sys/sys/disk_zone.h: Add a new API for managing zoned disks. This is very close to the SCSI ZBC and ATA ZAC standards, but uses integers in native byte order instead of big endian (SCSI) or little endian (ATA) byte arrays. This is intended to offer to the complete feature set of the ZBC and ZAC disk management without requiring the application developer to include SCSI or ATA headers. We also use one set of headers for ioctl consumers and kernel bio-level consumers. sys/sys/param.h: Bump __FreeBSD_version for sys/bio.h command changes, and inclusion of SMR support. usr.sbin/Makefile: Add the zonectl utility. usr.sbin/diskinfo/diskinfo.c Add disk zoning capability to the 'diskinfo -v' output. usr.sbin/zonectl/Makefile: Add zonectl makefile. usr.sbin/zonectl/zonectl.8 zonectl(8) man page. usr.sbin/zonectl/zonectl.c The zonectl(8) utility. This allows managing SCSI or ATA zoned disks via the disk_zone.h API. You can report zones, reset write pointers, get parameters, etc. Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D6147 Reviewed by: wblock (documentation)
2016-05-19 14:08:36 +00:00
/*cdb_storage*/ NULL,
/*cdb_storage_len*/ 0,
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*sense_len*/ SSD_FULL_SIZE,
/*timeout*/ timeout ? timeout : 30 * 1000,
/*is48bit*/ 0,
/*devtype*/ devtype);
Add support for managing Shingled Magnetic Recording (SMR) drives. This change includes support for SCSI SMR drives (which conform to the Zoned Block Commands or ZBC spec) and ATA SMR drives (which conform to the Zoned ATA Command Set or ZAC spec) behind SAS expanders. This includes full management support through the GEOM BIO interface, and through a new userland utility, zonectl(8), and through camcontrol(8). This is now ready for filesystems to use to detect and manage zoned drives. (There is no work in progress that I know of to use this for ZFS or UFS, if anyone is interested, let me know and I may have some suggestions.) Also, improve ATA command passthrough and dispatch support, both via ATA and ATA passthrough over SCSI. Also, add support to camcontrol(8) for the ATA Extended Power Conditions feature set. You can now manage ATA device power states, and set various idle time thresholds for a drive to enter lower power states. Note that this change cannot be MFCed in full, because it depends on changes to the struct bio API that break compatilibity. In order to avoid breaking the stable API, only changes that don't touch or depend on the struct bio changes can be merged. For example, the camcontrol(8) changes don't depend on the new bio API, but zonectl(8) and the probe changes to the da(4) and ada(4) drivers do depend on it. Also note that the SMR changes have not yet been tested with an actual SCSI ZBC device, or a SCSI to ATA translation layer (SAT) that supports ZBC to ZAC translation. I have not yet gotten a suitable drive or SAT layer, so any testing help would be appreciated. These changes have been tested with Seagate Host Aware SATA drives attached to both SAS and SATA controllers. Also, I do not have any SATA Host Managed devices, and I suspect that it may take additional (hopefully minor) changes to support them. Thanks to Seagate for supplying the test hardware and answering questions. sbin/camcontrol/Makefile: Add epc.c and zone.c. sbin/camcontrol/camcontrol.8: Document the zone and epc subcommands. sbin/camcontrol/camcontrol.c: Add the zone and epc subcommands. Add auxiliary register support to build_ata_cmd(). Make sure to set the CAM_ATAIO_NEEDRESULT, CAM_ATAIO_DMA, and CAM_ATAIO_FPDMA flags as appropriate for ATA commands. Add a new get_ata_status() function to parse ATA result from SCSI sense descriptors (for ATA passthrough over SCSI) and ATA I/O requests. sbin/camcontrol/camcontrol.h: Update the build_ata_cmd() prototype Add get_ata_status(), zone(), and epc(). sbin/camcontrol/epc.c: Support for ATA Extended Power Conditions features. This includes support for all features documented in the ACS-4 Revision 12 specification from t13.org (dated February 18, 2016). The EPC feature set allows putting a drive into a power power mode immediately, or setting timeouts so that the drive will automatically enter progressively lower power states after various idle times. sbin/camcontrol/fwdownload.c: Update the firmware download code for the new build_ata_cmd() arguments. sbin/camcontrol/zone.c: Implement support for Shingled Magnetic Recording (SMR) drives via SCSI Zoned Block Commands (ZBC) and ATA Zoned Device ATA Command Set (ZAC). These specs were developed in concert, and are functionally identical. The primary differences are due to SCSI and ATA differences. (SCSI is big endian, ATA is little endian, for example.) This includes support for all commands defined in the ZBC and ZAC specs. sys/cam/ata/ata_all.c: Decode a number of additional ATA command names in ata_op_string(). Add a new CCB building function, ata_read_log(). Add ata_zac_mgmt_in() and ata_zac_mgmt_out() CCB building functions. These support both DMA and NCQ encapsulation. sys/cam/ata/ata_all.h: Add prototypes for ata_read_log(), ata_zac_mgmt_out(), and ata_zac_mgmt_in(). sys/cam/ata/ata_da.c: Revamp the ada(4) driver to support zoned devices. Add four new probe states to gather information needed for zone support. Add a new adasetflags() function to avoid duplication of large blocks of flag setting between the async handler and register functions. Add new sysctl variables that describe zone support and paramters. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. sys/cam/scsi/scsi_all.c: Add command descriptions for the ZBC IN/OUT commands. Add descriptions for ZBC Host Managed devices. Add a new function, scsi_ata_pass() to do ATA passthrough over SCSI. This will eventually replace scsi_ata_pass_16() -- it can create the 12, 16, and 32-byte variants of the ATA PASS-THROUGH command, and supports setting all of the registers defined as of SAT-4, Revision 5 (March 11, 2016). Change scsi_ata_identify() to use scsi_ata_pass() instead of scsi_ata_pass_16(). Add a new scsi_ata_read_log() function to facilitate reading ATA logs via SCSI. sys/cam/scsi/scsi_all.h: Add the new ATA PASS-THROUGH(32) command CDB. Add extended and variable CDB opcodes. Add Zoned Block Device Characteristics VPD page. Add ATA Return SCSI sense descriptor. Add prototypes for scsi_ata_read_log() and scsi_ata_pass(). sys/cam/scsi/scsi_da.c: Revamp the da(4) driver to support zoned devices. Add five new probe states, four of which are needed for ATA devices. Add five new sysctl variables that describe zone support and parameters. The da(4) driver supports SCSI ZBC devices, as well as ATA ZAC devices when they are attached via a SCSI to ATA Translation (SAT) layer. Since ZBC -> ZAC translation is a new feature in the T10 SAT-4 spec, most SATA drives will be supported via ATA commands sent via the SCSI ATA PASS-THROUGH command. The da(4) driver will prefer the ZBC interface, if it is available, for performance reasons, but will use the ATA PASS-THROUGH interface to the ZAC command set if the SAT layer doesn't support translation yet. As I mentioned above, ZBC command support is untested. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. Add scsi_zbc_in() and scsi_zbc_out() CCB building functions. Add scsi_ata_zac_mgmt_out() and scsi_ata_zac_mgmt_in() CCB/CDB building functions. Note that these have return values, unlike almost all other CCB building functions in CAM. The reason is that they can fail, depending upon the particular combination of input parameters. The primary failure case is if the user wants NCQ, but fails to specify additional CDB storage. NCQ requires using the 32-byte version of the SCSI ATA PASS-THROUGH command, and the current CAM CDB size is 16 bytes. sys/cam/scsi/scsi_da.h: Add ZBC IN and ZBC OUT CDBs and opcodes. Add SCSI Report Zones data structures. Add scsi_zbc_in(), scsi_zbc_out(), scsi_ata_zac_mgmt_out(), and scsi_ata_zac_mgmt_in() prototypes. sys/dev/ahci/ahci.c: Fix SEND / RECEIVE FPDMA QUEUED in the ahci(4) driver. ahci_setup_fis() previously set the top bits of the sector count register in the FIS to 0 for FPDMA commands. This is okay for read and write, because the PRIO field is in the only thing in those bits, and we don't implement that further up the stack. But, for SEND and RECEIVE FPDMA QUEUED, the subcommand is in that byte, so it needs to be transmitted to the drive. In ahci_setup_fis(), always set the the top 8 bits of the sector count register. We need it in both the standard and NCQ / FPDMA cases. sys/geom/eli/g_eli.c: Pass BIO_ZONE commands through the GELI class. sys/geom/geom.h: Add g_io_zonecmd() prototype. sys/geom/geom_dev.c: Add new DIOCZONECMD ioctl, which allows sending zone commands to disks. sys/geom/geom_disk.c: Add support for BIO_ZONE commands. sys/geom/geom_disk.h: Add a new flag, DISKFLAG_CANZONE, that indicates that a given GEOM disk client can handle BIO_ZONE commands. sys/geom/geom_io.c: Add a new function, g_io_zonecmd(), that handles execution of BIO_ZONE commands. Add permissions check for BIO_ZONE commands. Add command decoding for BIO_ZONE commands. sys/geom/geom_subr.c: Add DDB command decoding for BIO_ZONE commands. sys/kern/subr_devstat.c: Record statistics for REPORT ZONES commands. Note that the number of bytes transferred for REPORT ZONES won't quite match what is received from the harware. This is because we're necessarily counting bytes coming from the da(4) / ada(4) drivers, which are using the disk_zone.h interface to communicate up the stack. The structure sizes it uses are slightly different than the SCSI and ATA structure sizes. sys/sys/ata.h: Add many bit and structure definitions for ZAC, NCQ, and EPC command support. sys/sys/bio.h: Convert the bio_cmd field to a straight enumeration. This will yield more space for additional commands in the future. After change r297955 and other related changes, this is now possible. Converting to an enumeration will also prevent use as a bitmask in the future. sys/sys/disk.h: Define the DIOCZONECMD ioctl. sys/sys/disk_zone.h: Add a new API for managing zoned disks. This is very close to the SCSI ZBC and ATA ZAC standards, but uses integers in native byte order instead of big endian (SCSI) or little endian (ATA) byte arrays. This is intended to offer to the complete feature set of the ZBC and ZAC disk management without requiring the application developer to include SCSI or ATA headers. We also use one set of headers for ioctl consumers and kernel bio-level consumers. sys/sys/param.h: Bump __FreeBSD_version for sys/bio.h command changes, and inclusion of SMR support. usr.sbin/Makefile: Add the zonectl utility. usr.sbin/diskinfo/diskinfo.c Add disk zoning capability to the 'diskinfo -v' output. usr.sbin/zonectl/Makefile: Add zonectl makefile. usr.sbin/zonectl/zonectl.8 zonectl(8) man page. usr.sbin/zonectl/zonectl.c The zonectl(8) utility. This allows managing SCSI or ATA zoned disks via the disk_zone.h API. You can report zones, reset write pointers, get parameters, etc. Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D6147 Reviewed by: wblock (documentation)
2016-05-19 14:08:36 +00:00
if (retval != 0) {
retval = -1;
warnx("%s: build_ata_cmd() failed, likely "
"programmer error", __func__);
goto bailout;
}
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
break;
}
default:
warnx("Unknown disk type %d", devtype);
retval = -1;
goto bailout;
break; /*NOTREACHED*/
}
ccb->ccb_h.flags |= CAM_DEV_QFRZDIS;
retval = cam_send_ccb(dev, ccb);
if (retval != 0) {
warn("error sending %s CCB", (devtype == CC_DT_SCSI) ?
"Test Unit Ready" : "Identify");
retval = -1;
goto bailout;
}
if (((ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP)
&& (vp->tur_status == FW_TUR_READY)) {
warnx("Device is not ready");
if (printerrors)
cam_error_print(dev, ccb, CAM_ESF_ALL,
CAM_EPF_ALL, stderr);
retval = 1;
goto bailout;
} else if (((ccb->ccb_h.status & CAM_STATUS_MASK) == CAM_REQ_CMP)
&& (vp->tur_status == FW_TUR_NOT_READY)) {
warnx("Device cannot have media loaded when firmware is "
"downloaded");
retval = 1;
goto bailout;
}
bailout:
Fix memory leaks in camcontrol Reported by: Coverity CID: 1331674, 1331675 Reviewed by: ken MFC after: 3 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D10588
2017-05-03 19:56:55 +00:00
free(ptr);
cam_freeccb(ccb);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
return (retval);
}
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
/*
* Download firmware stored in buf to cam_dev. If simulation mode
* is enabled, only show what packet sizes would be sent to the
* device but do not sent any actual packets
*/
static int
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
fw_download_img(struct cam_device *cam_dev, struct fw_vendor *vp,
char *buf, int img_size, int sim_mode, int printerrors, int quiet,
int retry_count, int timeout, const char *imgname,
camcontrol_devtype devtype)
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
{
struct scsi_write_buffer cdb;
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
progress_t progress;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
int size = 0;
union ccb *ccb = NULL;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
int pkt_count = 0;
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
int max_pkt_size;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
u_int32_t pkt_size = 0;
char *pkt_ptr = buf;
u_int32_t offset;
int last_pkt = 0;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
int retval = 0;
/*
* Check to see whether the device is ready to accept a firmware
* download.
*/
retval = fw_check_device_ready(cam_dev, devtype, vp, printerrors,
timeout);
if (retval != 0)
goto bailout;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
if ((ccb = cam_getccb(cam_dev)) == NULL) {
warnx("Could not allocate CCB");
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
retval = 1;
goto bailout;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
}
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
Fix multiple Coverity Out-of-bounds access false postive issues in CAM The currently used idiom for clearing the part of a ccb after its header generates one or two Coverity errors for each time it is used. All instances generate an Out-of-bounds access (ARRAY_VS_SINGLETON) error because of the treatment of the header as a two element array, with a pointer to the non-existent second element being passed as the starting address to bzero(). Some instances also alsp generate Out-of-bounds access (OVERRUN) errors, probably because the space being cleared is larger than the sizeofstruct ccb_hdr). In addition, this idiom is difficult for humans to understand and it is error prone. The user has to chose the proper struct ccb_* type (which does not appear in the surrounding code) for the sizeof() in the length calculation. I found several instances where the length was incorrect, which could cause either an actual out of bounds write, or incompletely clear the ccb. A better way is to write the code to clear the ccb itself starting at sizeof(ccb_hdr) bytes from the start of the ccb, and calculate the length based on the specific type of struct ccb_* being cleared as specified by the union ccb member being used. The latter can normally be seen in the nearby code. This is friendlier for Coverity and other static analysis tools because they will see that the intent is to clear the trailing part of the ccb. Wrap all of the boilerplate code in a convenient macro that only requires a pointer to the desired union ccb member (or a pointer to the union ccb itself) as an argument. Reported by: Coverity CID: 1007578, 1008684, 1009724, 1009773, 1011304, 1011306 CID: 1011307, 1011308, 1011309, 1011310, 1011311, 1011312 CID: 1011313, 1011314, 1011315, 1011316, 1011317, 1011318 CID: 1011319, 1011320, 1011321, 1011322, 1011324, 1011325 CID: 1011326, 1011327, 1011328, 1011329, 1011330, 1011374 CID: 1011390, 1011391, 1011392, 1011393, 1011394, 1011395 CID: 1011396, 1011397, 1011398, 1011399, 1011400, 1011401 CID: 1011402, 1011403, 1011404, 1011405, 1011406, 1011408 CID: 1011409, 1011410, 1011411, 1011412, 1011413, 1011414 CID: 1017461, 1018387, 1086860, 1086874, 1194257, 1229897 CID: 1229968, 1306229, 1306234, 1331282, 1331283, 1331294 CID: 1331295, 1331535, 1331536, 1331539, 1331540, 1341623 CID: 1341624, 1341637, 1341638, 1355264, 1355324 Reviewed by: scottl, ken, delphij, imp MFH: 1 month Differential Revision: https://reviews.freebsd.org/D6496
2016-05-24 00:57:11 +00:00
CCB_CLEAR_ALL_EXCEPT_HDR(ccb);
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
max_pkt_size = vp->max_pkt_size;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
if (max_pkt_size == 0)
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
max_pkt_size = UNKNOWN_MAX_PKT_SIZE;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
pkt_size = max_pkt_size;
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
progress_init(&progress, imgname, size = img_size);
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
/* Download single fw packets. */
do {
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
if (img_size <= max_pkt_size) {
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
last_pkt = 1;
pkt_size = img_size;
}
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
progress_update(&progress, size - img_size);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
if (((sim_mode == 0) && (quiet == 0))
|| ((sim_mode != 0) && (printerrors == 0)))
progress_draw(&progress);
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
bzero(&cdb, sizeof(cdb));
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
switch (devtype) {
case CC_DT_SCSI:
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
cdb.opcode = WRITE_BUFFER;
cdb.control = 0;
/* Parameter list length. */
scsi_ulto3b(pkt_size, &cdb.length[0]);
offset = vp->inc_cdb_offset ? (pkt_ptr - buf) : 0;
scsi_ulto3b(offset, &cdb.offset[0]);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
cdb.byte2 = last_pkt ? vp->cdb_byte2_last :
vp->cdb_byte2;
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
cdb.buffer_id = vp->inc_cdb_buffer_id ? pkt_count : 0;
/* Zero out payload of ccb union after ccb header. */
Fix multiple Coverity Out-of-bounds access false postive issues in CAM The currently used idiom for clearing the part of a ccb after its header generates one or two Coverity errors for each time it is used. All instances generate an Out-of-bounds access (ARRAY_VS_SINGLETON) error because of the treatment of the header as a two element array, with a pointer to the non-existent second element being passed as the starting address to bzero(). Some instances also alsp generate Out-of-bounds access (OVERRUN) errors, probably because the space being cleared is larger than the sizeofstruct ccb_hdr). In addition, this idiom is difficult for humans to understand and it is error prone. The user has to chose the proper struct ccb_* type (which does not appear in the surrounding code) for the sizeof() in the length calculation. I found several instances where the length was incorrect, which could cause either an actual out of bounds write, or incompletely clear the ccb. A better way is to write the code to clear the ccb itself starting at sizeof(ccb_hdr) bytes from the start of the ccb, and calculate the length based on the specific type of struct ccb_* being cleared as specified by the union ccb member being used. The latter can normally be seen in the nearby code. This is friendlier for Coverity and other static analysis tools because they will see that the intent is to clear the trailing part of the ccb. Wrap all of the boilerplate code in a convenient macro that only requires a pointer to the desired union ccb member (or a pointer to the union ccb itself) as an argument. Reported by: Coverity CID: 1007578, 1008684, 1009724, 1009773, 1011304, 1011306 CID: 1011307, 1011308, 1011309, 1011310, 1011311, 1011312 CID: 1011313, 1011314, 1011315, 1011316, 1011317, 1011318 CID: 1011319, 1011320, 1011321, 1011322, 1011324, 1011325 CID: 1011326, 1011327, 1011328, 1011329, 1011330, 1011374 CID: 1011390, 1011391, 1011392, 1011393, 1011394, 1011395 CID: 1011396, 1011397, 1011398, 1011399, 1011400, 1011401 CID: 1011402, 1011403, 1011404, 1011405, 1011406, 1011408 CID: 1011409, 1011410, 1011411, 1011412, 1011413, 1011414 CID: 1017461, 1018387, 1086860, 1086874, 1194257, 1229897 CID: 1229968, 1306229, 1306234, 1331282, 1331283, 1331294 CID: 1331295, 1331535, 1331536, 1331539, 1331540, 1341623 CID: 1341624, 1341637, 1341638, 1355264, 1355324 Reviewed by: scottl, ken, delphij, imp MFH: 1 month Differential Revision: https://reviews.freebsd.org/D6496
2016-05-24 00:57:11 +00:00
CCB_CLEAR_ALL_EXCEPT_HDR(&ccb->csio);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*
* Copy previously constructed cdb into ccb_scsiio
* struct.
*/
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
bcopy(&cdb, &ccb->csio.cdb_io.cdb_bytes[0],
sizeof(struct scsi_write_buffer));
/* Fill rest of ccb_scsiio struct. */
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
cam_fill_csio(&ccb->csio, /* ccb_scsiio*/
retry_count, /* retries*/
NULL, /* cbfcnp*/
CAM_DIR_OUT | CAM_DEV_QFRZDIS, /* flags*/
CAM_TAG_ACTION_NONE, /* tag_action*/
(u_char *)pkt_ptr, /* data_ptr*/
pkt_size, /* dxfer_len*/
SSD_FULL_SIZE, /* sense_len*/
sizeof(struct scsi_write_buffer), /* cdb_len*/
timeout ? timeout : WB_TIMEOUT); /* timeout*/
break;
case CC_DT_ATA:
Use the more proper term of SATL instead of ATA_BEHIND_SCSI. Most people know SAS attached SATA devices by the name SAT or SATL (with the latter being a little more common). Change the device type ATA_BEHIND_SCSI to SATL since it's more specific and meaningful. Suggested by: scottl@
2019-07-15 20:25:41 +00:00
case CC_DT_SATL: {
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
uint32_t off;
off = (uint32_t)(pkt_ptr - buf);
Add support for managing Shingled Magnetic Recording (SMR) drives. This change includes support for SCSI SMR drives (which conform to the Zoned Block Commands or ZBC spec) and ATA SMR drives (which conform to the Zoned ATA Command Set or ZAC spec) behind SAS expanders. This includes full management support through the GEOM BIO interface, and through a new userland utility, zonectl(8), and through camcontrol(8). This is now ready for filesystems to use to detect and manage zoned drives. (There is no work in progress that I know of to use this for ZFS or UFS, if anyone is interested, let me know and I may have some suggestions.) Also, improve ATA command passthrough and dispatch support, both via ATA and ATA passthrough over SCSI. Also, add support to camcontrol(8) for the ATA Extended Power Conditions feature set. You can now manage ATA device power states, and set various idle time thresholds for a drive to enter lower power states. Note that this change cannot be MFCed in full, because it depends on changes to the struct bio API that break compatilibity. In order to avoid breaking the stable API, only changes that don't touch or depend on the struct bio changes can be merged. For example, the camcontrol(8) changes don't depend on the new bio API, but zonectl(8) and the probe changes to the da(4) and ada(4) drivers do depend on it. Also note that the SMR changes have not yet been tested with an actual SCSI ZBC device, or a SCSI to ATA translation layer (SAT) that supports ZBC to ZAC translation. I have not yet gotten a suitable drive or SAT layer, so any testing help would be appreciated. These changes have been tested with Seagate Host Aware SATA drives attached to both SAS and SATA controllers. Also, I do not have any SATA Host Managed devices, and I suspect that it may take additional (hopefully minor) changes to support them. Thanks to Seagate for supplying the test hardware and answering questions. sbin/camcontrol/Makefile: Add epc.c and zone.c. sbin/camcontrol/camcontrol.8: Document the zone and epc subcommands. sbin/camcontrol/camcontrol.c: Add the zone and epc subcommands. Add auxiliary register support to build_ata_cmd(). Make sure to set the CAM_ATAIO_NEEDRESULT, CAM_ATAIO_DMA, and CAM_ATAIO_FPDMA flags as appropriate for ATA commands. Add a new get_ata_status() function to parse ATA result from SCSI sense descriptors (for ATA passthrough over SCSI) and ATA I/O requests. sbin/camcontrol/camcontrol.h: Update the build_ata_cmd() prototype Add get_ata_status(), zone(), and epc(). sbin/camcontrol/epc.c: Support for ATA Extended Power Conditions features. This includes support for all features documented in the ACS-4 Revision 12 specification from t13.org (dated February 18, 2016). The EPC feature set allows putting a drive into a power power mode immediately, or setting timeouts so that the drive will automatically enter progressively lower power states after various idle times. sbin/camcontrol/fwdownload.c: Update the firmware download code for the new build_ata_cmd() arguments. sbin/camcontrol/zone.c: Implement support for Shingled Magnetic Recording (SMR) drives via SCSI Zoned Block Commands (ZBC) and ATA Zoned Device ATA Command Set (ZAC). These specs were developed in concert, and are functionally identical. The primary differences are due to SCSI and ATA differences. (SCSI is big endian, ATA is little endian, for example.) This includes support for all commands defined in the ZBC and ZAC specs. sys/cam/ata/ata_all.c: Decode a number of additional ATA command names in ata_op_string(). Add a new CCB building function, ata_read_log(). Add ata_zac_mgmt_in() and ata_zac_mgmt_out() CCB building functions. These support both DMA and NCQ encapsulation. sys/cam/ata/ata_all.h: Add prototypes for ata_read_log(), ata_zac_mgmt_out(), and ata_zac_mgmt_in(). sys/cam/ata/ata_da.c: Revamp the ada(4) driver to support zoned devices. Add four new probe states to gather information needed for zone support. Add a new adasetflags() function to avoid duplication of large blocks of flag setting between the async handler and register functions. Add new sysctl variables that describe zone support and paramters. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. sys/cam/scsi/scsi_all.c: Add command descriptions for the ZBC IN/OUT commands. Add descriptions for ZBC Host Managed devices. Add a new function, scsi_ata_pass() to do ATA passthrough over SCSI. This will eventually replace scsi_ata_pass_16() -- it can create the 12, 16, and 32-byte variants of the ATA PASS-THROUGH command, and supports setting all of the registers defined as of SAT-4, Revision 5 (March 11, 2016). Change scsi_ata_identify() to use scsi_ata_pass() instead of scsi_ata_pass_16(). Add a new scsi_ata_read_log() function to facilitate reading ATA logs via SCSI. sys/cam/scsi/scsi_all.h: Add the new ATA PASS-THROUGH(32) command CDB. Add extended and variable CDB opcodes. Add Zoned Block Device Characteristics VPD page. Add ATA Return SCSI sense descriptor. Add prototypes for scsi_ata_read_log() and scsi_ata_pass(). sys/cam/scsi/scsi_da.c: Revamp the da(4) driver to support zoned devices. Add five new probe states, four of which are needed for ATA devices. Add five new sysctl variables that describe zone support and parameters. The da(4) driver supports SCSI ZBC devices, as well as ATA ZAC devices when they are attached via a SCSI to ATA Translation (SAT) layer. Since ZBC -> ZAC translation is a new feature in the T10 SAT-4 spec, most SATA drives will be supported via ATA commands sent via the SCSI ATA PASS-THROUGH command. The da(4) driver will prefer the ZBC interface, if it is available, for performance reasons, but will use the ATA PASS-THROUGH interface to the ZAC command set if the SAT layer doesn't support translation yet. As I mentioned above, ZBC command support is untested. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. Add scsi_zbc_in() and scsi_zbc_out() CCB building functions. Add scsi_ata_zac_mgmt_out() and scsi_ata_zac_mgmt_in() CCB/CDB building functions. Note that these have return values, unlike almost all other CCB building functions in CAM. The reason is that they can fail, depending upon the particular combination of input parameters. The primary failure case is if the user wants NCQ, but fails to specify additional CDB storage. NCQ requires using the 32-byte version of the SCSI ATA PASS-THROUGH command, and the current CAM CDB size is 16 bytes. sys/cam/scsi/scsi_da.h: Add ZBC IN and ZBC OUT CDBs and opcodes. Add SCSI Report Zones data structures. Add scsi_zbc_in(), scsi_zbc_out(), scsi_ata_zac_mgmt_out(), and scsi_ata_zac_mgmt_in() prototypes. sys/dev/ahci/ahci.c: Fix SEND / RECEIVE FPDMA QUEUED in the ahci(4) driver. ahci_setup_fis() previously set the top bits of the sector count register in the FIS to 0 for FPDMA commands. This is okay for read and write, because the PRIO field is in the only thing in those bits, and we don't implement that further up the stack. But, for SEND and RECEIVE FPDMA QUEUED, the subcommand is in that byte, so it needs to be transmitted to the drive. In ahci_setup_fis(), always set the the top 8 bits of the sector count register. We need it in both the standard and NCQ / FPDMA cases. sys/geom/eli/g_eli.c: Pass BIO_ZONE commands through the GELI class. sys/geom/geom.h: Add g_io_zonecmd() prototype. sys/geom/geom_dev.c: Add new DIOCZONECMD ioctl, which allows sending zone commands to disks. sys/geom/geom_disk.c: Add support for BIO_ZONE commands. sys/geom/geom_disk.h: Add a new flag, DISKFLAG_CANZONE, that indicates that a given GEOM disk client can handle BIO_ZONE commands. sys/geom/geom_io.c: Add a new function, g_io_zonecmd(), that handles execution of BIO_ZONE commands. Add permissions check for BIO_ZONE commands. Add command decoding for BIO_ZONE commands. sys/geom/geom_subr.c: Add DDB command decoding for BIO_ZONE commands. sys/kern/subr_devstat.c: Record statistics for REPORT ZONES commands. Note that the number of bytes transferred for REPORT ZONES won't quite match what is received from the harware. This is because we're necessarily counting bytes coming from the da(4) / ada(4) drivers, which are using the disk_zone.h interface to communicate up the stack. The structure sizes it uses are slightly different than the SCSI and ATA structure sizes. sys/sys/ata.h: Add many bit and structure definitions for ZAC, NCQ, and EPC command support. sys/sys/bio.h: Convert the bio_cmd field to a straight enumeration. This will yield more space for additional commands in the future. After change r297955 and other related changes, this is now possible. Converting to an enumeration will also prevent use as a bitmask in the future. sys/sys/disk.h: Define the DIOCZONECMD ioctl. sys/sys/disk_zone.h: Add a new API for managing zoned disks. This is very close to the SCSI ZBC and ATA ZAC standards, but uses integers in native byte order instead of big endian (SCSI) or little endian (ATA) byte arrays. This is intended to offer to the complete feature set of the ZBC and ZAC disk management without requiring the application developer to include SCSI or ATA headers. We also use one set of headers for ioctl consumers and kernel bio-level consumers. sys/sys/param.h: Bump __FreeBSD_version for sys/bio.h command changes, and inclusion of SMR support. usr.sbin/Makefile: Add the zonectl utility. usr.sbin/diskinfo/diskinfo.c Add disk zoning capability to the 'diskinfo -v' output. usr.sbin/zonectl/Makefile: Add zonectl makefile. usr.sbin/zonectl/zonectl.8 zonectl(8) man page. usr.sbin/zonectl/zonectl.c The zonectl(8) utility. This allows managing SCSI or ATA zoned disks via the disk_zone.h API. You can report zones, reset write pointers, get parameters, etc. Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D6147 Reviewed by: wblock (documentation)
2016-05-19 14:08:36 +00:00
retval = build_ata_cmd(ccb,
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*retry_count*/ retry_count,
/*flags*/ CAM_DIR_OUT | CAM_DEV_QFRZDIS,
/*tag_action*/ CAM_TAG_ACTION_NONE,
/*protocol*/ AP_PROTO_PIO_OUT,
/*ata_flags*/ AP_FLAG_BYT_BLOK_BYTES |
AP_FLAG_TLEN_SECT_CNT |
AP_FLAG_TDIR_TO_DEV,
/*features*/ USE_OFFSETS_FEATURE,
/*sector_count*/ ATA_MAKE_SECTORS(pkt_size),
/*lba*/ ATA_MAKE_LBA(off, pkt_size),
/*command*/ ATA_DOWNLOAD_MICROCODE,
Add support for managing Shingled Magnetic Recording (SMR) drives. This change includes support for SCSI SMR drives (which conform to the Zoned Block Commands or ZBC spec) and ATA SMR drives (which conform to the Zoned ATA Command Set or ZAC spec) behind SAS expanders. This includes full management support through the GEOM BIO interface, and through a new userland utility, zonectl(8), and through camcontrol(8). This is now ready for filesystems to use to detect and manage zoned drives. (There is no work in progress that I know of to use this for ZFS or UFS, if anyone is interested, let me know and I may have some suggestions.) Also, improve ATA command passthrough and dispatch support, both via ATA and ATA passthrough over SCSI. Also, add support to camcontrol(8) for the ATA Extended Power Conditions feature set. You can now manage ATA device power states, and set various idle time thresholds for a drive to enter lower power states. Note that this change cannot be MFCed in full, because it depends on changes to the struct bio API that break compatilibity. In order to avoid breaking the stable API, only changes that don't touch or depend on the struct bio changes can be merged. For example, the camcontrol(8) changes don't depend on the new bio API, but zonectl(8) and the probe changes to the da(4) and ada(4) drivers do depend on it. Also note that the SMR changes have not yet been tested with an actual SCSI ZBC device, or a SCSI to ATA translation layer (SAT) that supports ZBC to ZAC translation. I have not yet gotten a suitable drive or SAT layer, so any testing help would be appreciated. These changes have been tested with Seagate Host Aware SATA drives attached to both SAS and SATA controllers. Also, I do not have any SATA Host Managed devices, and I suspect that it may take additional (hopefully minor) changes to support them. Thanks to Seagate for supplying the test hardware and answering questions. sbin/camcontrol/Makefile: Add epc.c and zone.c. sbin/camcontrol/camcontrol.8: Document the zone and epc subcommands. sbin/camcontrol/camcontrol.c: Add the zone and epc subcommands. Add auxiliary register support to build_ata_cmd(). Make sure to set the CAM_ATAIO_NEEDRESULT, CAM_ATAIO_DMA, and CAM_ATAIO_FPDMA flags as appropriate for ATA commands. Add a new get_ata_status() function to parse ATA result from SCSI sense descriptors (for ATA passthrough over SCSI) and ATA I/O requests. sbin/camcontrol/camcontrol.h: Update the build_ata_cmd() prototype Add get_ata_status(), zone(), and epc(). sbin/camcontrol/epc.c: Support for ATA Extended Power Conditions features. This includes support for all features documented in the ACS-4 Revision 12 specification from t13.org (dated February 18, 2016). The EPC feature set allows putting a drive into a power power mode immediately, or setting timeouts so that the drive will automatically enter progressively lower power states after various idle times. sbin/camcontrol/fwdownload.c: Update the firmware download code for the new build_ata_cmd() arguments. sbin/camcontrol/zone.c: Implement support for Shingled Magnetic Recording (SMR) drives via SCSI Zoned Block Commands (ZBC) and ATA Zoned Device ATA Command Set (ZAC). These specs were developed in concert, and are functionally identical. The primary differences are due to SCSI and ATA differences. (SCSI is big endian, ATA is little endian, for example.) This includes support for all commands defined in the ZBC and ZAC specs. sys/cam/ata/ata_all.c: Decode a number of additional ATA command names in ata_op_string(). Add a new CCB building function, ata_read_log(). Add ata_zac_mgmt_in() and ata_zac_mgmt_out() CCB building functions. These support both DMA and NCQ encapsulation. sys/cam/ata/ata_all.h: Add prototypes for ata_read_log(), ata_zac_mgmt_out(), and ata_zac_mgmt_in(). sys/cam/ata/ata_da.c: Revamp the ada(4) driver to support zoned devices. Add four new probe states to gather information needed for zone support. Add a new adasetflags() function to avoid duplication of large blocks of flag setting between the async handler and register functions. Add new sysctl variables that describe zone support and paramters. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. sys/cam/scsi/scsi_all.c: Add command descriptions for the ZBC IN/OUT commands. Add descriptions for ZBC Host Managed devices. Add a new function, scsi_ata_pass() to do ATA passthrough over SCSI. This will eventually replace scsi_ata_pass_16() -- it can create the 12, 16, and 32-byte variants of the ATA PASS-THROUGH command, and supports setting all of the registers defined as of SAT-4, Revision 5 (March 11, 2016). Change scsi_ata_identify() to use scsi_ata_pass() instead of scsi_ata_pass_16(). Add a new scsi_ata_read_log() function to facilitate reading ATA logs via SCSI. sys/cam/scsi/scsi_all.h: Add the new ATA PASS-THROUGH(32) command CDB. Add extended and variable CDB opcodes. Add Zoned Block Device Characteristics VPD page. Add ATA Return SCSI sense descriptor. Add prototypes for scsi_ata_read_log() and scsi_ata_pass(). sys/cam/scsi/scsi_da.c: Revamp the da(4) driver to support zoned devices. Add five new probe states, four of which are needed for ATA devices. Add five new sysctl variables that describe zone support and parameters. The da(4) driver supports SCSI ZBC devices, as well as ATA ZAC devices when they are attached via a SCSI to ATA Translation (SAT) layer. Since ZBC -> ZAC translation is a new feature in the T10 SAT-4 spec, most SATA drives will be supported via ATA commands sent via the SCSI ATA PASS-THROUGH command. The da(4) driver will prefer the ZBC interface, if it is available, for performance reasons, but will use the ATA PASS-THROUGH interface to the ZAC command set if the SAT layer doesn't support translation yet. As I mentioned above, ZBC command support is untested. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. Add scsi_zbc_in() and scsi_zbc_out() CCB building functions. Add scsi_ata_zac_mgmt_out() and scsi_ata_zac_mgmt_in() CCB/CDB building functions. Note that these have return values, unlike almost all other CCB building functions in CAM. The reason is that they can fail, depending upon the particular combination of input parameters. The primary failure case is if the user wants NCQ, but fails to specify additional CDB storage. NCQ requires using the 32-byte version of the SCSI ATA PASS-THROUGH command, and the current CAM CDB size is 16 bytes. sys/cam/scsi/scsi_da.h: Add ZBC IN and ZBC OUT CDBs and opcodes. Add SCSI Report Zones data structures. Add scsi_zbc_in(), scsi_zbc_out(), scsi_ata_zac_mgmt_out(), and scsi_ata_zac_mgmt_in() prototypes. sys/dev/ahci/ahci.c: Fix SEND / RECEIVE FPDMA QUEUED in the ahci(4) driver. ahci_setup_fis() previously set the top bits of the sector count register in the FIS to 0 for FPDMA commands. This is okay for read and write, because the PRIO field is in the only thing in those bits, and we don't implement that further up the stack. But, for SEND and RECEIVE FPDMA QUEUED, the subcommand is in that byte, so it needs to be transmitted to the drive. In ahci_setup_fis(), always set the the top 8 bits of the sector count register. We need it in both the standard and NCQ / FPDMA cases. sys/geom/eli/g_eli.c: Pass BIO_ZONE commands through the GELI class. sys/geom/geom.h: Add g_io_zonecmd() prototype. sys/geom/geom_dev.c: Add new DIOCZONECMD ioctl, which allows sending zone commands to disks. sys/geom/geom_disk.c: Add support for BIO_ZONE commands. sys/geom/geom_disk.h: Add a new flag, DISKFLAG_CANZONE, that indicates that a given GEOM disk client can handle BIO_ZONE commands. sys/geom/geom_io.c: Add a new function, g_io_zonecmd(), that handles execution of BIO_ZONE commands. Add permissions check for BIO_ZONE commands. Add command decoding for BIO_ZONE commands. sys/geom/geom_subr.c: Add DDB command decoding for BIO_ZONE commands. sys/kern/subr_devstat.c: Record statistics for REPORT ZONES commands. Note that the number of bytes transferred for REPORT ZONES won't quite match what is received from the harware. This is because we're necessarily counting bytes coming from the da(4) / ada(4) drivers, which are using the disk_zone.h interface to communicate up the stack. The structure sizes it uses are slightly different than the SCSI and ATA structure sizes. sys/sys/ata.h: Add many bit and structure definitions for ZAC, NCQ, and EPC command support. sys/sys/bio.h: Convert the bio_cmd field to a straight enumeration. This will yield more space for additional commands in the future. After change r297955 and other related changes, this is now possible. Converting to an enumeration will also prevent use as a bitmask in the future. sys/sys/disk.h: Define the DIOCZONECMD ioctl. sys/sys/disk_zone.h: Add a new API for managing zoned disks. This is very close to the SCSI ZBC and ATA ZAC standards, but uses integers in native byte order instead of big endian (SCSI) or little endian (ATA) byte arrays. This is intended to offer to the complete feature set of the ZBC and ZAC disk management without requiring the application developer to include SCSI or ATA headers. We also use one set of headers for ioctl consumers and kernel bio-level consumers. sys/sys/param.h: Bump __FreeBSD_version for sys/bio.h command changes, and inclusion of SMR support. usr.sbin/Makefile: Add the zonectl utility. usr.sbin/diskinfo/diskinfo.c Add disk zoning capability to the 'diskinfo -v' output. usr.sbin/zonectl/Makefile: Add zonectl makefile. usr.sbin/zonectl/zonectl.8 zonectl(8) man page. usr.sbin/zonectl/zonectl.c The zonectl(8) utility. This allows managing SCSI or ATA zoned disks via the disk_zone.h API. You can report zones, reset write pointers, get parameters, etc. Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D6147 Reviewed by: wblock (documentation)
2016-05-19 14:08:36 +00:00
/*auxiliary*/ 0,
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*data_ptr*/ (uint8_t *)pkt_ptr,
/*dxfer_len*/ pkt_size,
Add support for managing Shingled Magnetic Recording (SMR) drives. This change includes support for SCSI SMR drives (which conform to the Zoned Block Commands or ZBC spec) and ATA SMR drives (which conform to the Zoned ATA Command Set or ZAC spec) behind SAS expanders. This includes full management support through the GEOM BIO interface, and through a new userland utility, zonectl(8), and through camcontrol(8). This is now ready for filesystems to use to detect and manage zoned drives. (There is no work in progress that I know of to use this for ZFS or UFS, if anyone is interested, let me know and I may have some suggestions.) Also, improve ATA command passthrough and dispatch support, both via ATA and ATA passthrough over SCSI. Also, add support to camcontrol(8) for the ATA Extended Power Conditions feature set. You can now manage ATA device power states, and set various idle time thresholds for a drive to enter lower power states. Note that this change cannot be MFCed in full, because it depends on changes to the struct bio API that break compatilibity. In order to avoid breaking the stable API, only changes that don't touch or depend on the struct bio changes can be merged. For example, the camcontrol(8) changes don't depend on the new bio API, but zonectl(8) and the probe changes to the da(4) and ada(4) drivers do depend on it. Also note that the SMR changes have not yet been tested with an actual SCSI ZBC device, or a SCSI to ATA translation layer (SAT) that supports ZBC to ZAC translation. I have not yet gotten a suitable drive or SAT layer, so any testing help would be appreciated. These changes have been tested with Seagate Host Aware SATA drives attached to both SAS and SATA controllers. Also, I do not have any SATA Host Managed devices, and I suspect that it may take additional (hopefully minor) changes to support them. Thanks to Seagate for supplying the test hardware and answering questions. sbin/camcontrol/Makefile: Add epc.c and zone.c. sbin/camcontrol/camcontrol.8: Document the zone and epc subcommands. sbin/camcontrol/camcontrol.c: Add the zone and epc subcommands. Add auxiliary register support to build_ata_cmd(). Make sure to set the CAM_ATAIO_NEEDRESULT, CAM_ATAIO_DMA, and CAM_ATAIO_FPDMA flags as appropriate for ATA commands. Add a new get_ata_status() function to parse ATA result from SCSI sense descriptors (for ATA passthrough over SCSI) and ATA I/O requests. sbin/camcontrol/camcontrol.h: Update the build_ata_cmd() prototype Add get_ata_status(), zone(), and epc(). sbin/camcontrol/epc.c: Support for ATA Extended Power Conditions features. This includes support for all features documented in the ACS-4 Revision 12 specification from t13.org (dated February 18, 2016). The EPC feature set allows putting a drive into a power power mode immediately, or setting timeouts so that the drive will automatically enter progressively lower power states after various idle times. sbin/camcontrol/fwdownload.c: Update the firmware download code for the new build_ata_cmd() arguments. sbin/camcontrol/zone.c: Implement support for Shingled Magnetic Recording (SMR) drives via SCSI Zoned Block Commands (ZBC) and ATA Zoned Device ATA Command Set (ZAC). These specs were developed in concert, and are functionally identical. The primary differences are due to SCSI and ATA differences. (SCSI is big endian, ATA is little endian, for example.) This includes support for all commands defined in the ZBC and ZAC specs. sys/cam/ata/ata_all.c: Decode a number of additional ATA command names in ata_op_string(). Add a new CCB building function, ata_read_log(). Add ata_zac_mgmt_in() and ata_zac_mgmt_out() CCB building functions. These support both DMA and NCQ encapsulation. sys/cam/ata/ata_all.h: Add prototypes for ata_read_log(), ata_zac_mgmt_out(), and ata_zac_mgmt_in(). sys/cam/ata/ata_da.c: Revamp the ada(4) driver to support zoned devices. Add four new probe states to gather information needed for zone support. Add a new adasetflags() function to avoid duplication of large blocks of flag setting between the async handler and register functions. Add new sysctl variables that describe zone support and paramters. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. sys/cam/scsi/scsi_all.c: Add command descriptions for the ZBC IN/OUT commands. Add descriptions for ZBC Host Managed devices. Add a new function, scsi_ata_pass() to do ATA passthrough over SCSI. This will eventually replace scsi_ata_pass_16() -- it can create the 12, 16, and 32-byte variants of the ATA PASS-THROUGH command, and supports setting all of the registers defined as of SAT-4, Revision 5 (March 11, 2016). Change scsi_ata_identify() to use scsi_ata_pass() instead of scsi_ata_pass_16(). Add a new scsi_ata_read_log() function to facilitate reading ATA logs via SCSI. sys/cam/scsi/scsi_all.h: Add the new ATA PASS-THROUGH(32) command CDB. Add extended and variable CDB opcodes. Add Zoned Block Device Characteristics VPD page. Add ATA Return SCSI sense descriptor. Add prototypes for scsi_ata_read_log() and scsi_ata_pass(). sys/cam/scsi/scsi_da.c: Revamp the da(4) driver to support zoned devices. Add five new probe states, four of which are needed for ATA devices. Add five new sysctl variables that describe zone support and parameters. The da(4) driver supports SCSI ZBC devices, as well as ATA ZAC devices when they are attached via a SCSI to ATA Translation (SAT) layer. Since ZBC -> ZAC translation is a new feature in the T10 SAT-4 spec, most SATA drives will be supported via ATA commands sent via the SCSI ATA PASS-THROUGH command. The da(4) driver will prefer the ZBC interface, if it is available, for performance reasons, but will use the ATA PASS-THROUGH interface to the ZAC command set if the SAT layer doesn't support translation yet. As I mentioned above, ZBC command support is untested. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. Add scsi_zbc_in() and scsi_zbc_out() CCB building functions. Add scsi_ata_zac_mgmt_out() and scsi_ata_zac_mgmt_in() CCB/CDB building functions. Note that these have return values, unlike almost all other CCB building functions in CAM. The reason is that they can fail, depending upon the particular combination of input parameters. The primary failure case is if the user wants NCQ, but fails to specify additional CDB storage. NCQ requires using the 32-byte version of the SCSI ATA PASS-THROUGH command, and the current CAM CDB size is 16 bytes. sys/cam/scsi/scsi_da.h: Add ZBC IN and ZBC OUT CDBs and opcodes. Add SCSI Report Zones data structures. Add scsi_zbc_in(), scsi_zbc_out(), scsi_ata_zac_mgmt_out(), and scsi_ata_zac_mgmt_in() prototypes. sys/dev/ahci/ahci.c: Fix SEND / RECEIVE FPDMA QUEUED in the ahci(4) driver. ahci_setup_fis() previously set the top bits of the sector count register in the FIS to 0 for FPDMA commands. This is okay for read and write, because the PRIO field is in the only thing in those bits, and we don't implement that further up the stack. But, for SEND and RECEIVE FPDMA QUEUED, the subcommand is in that byte, so it needs to be transmitted to the drive. In ahci_setup_fis(), always set the the top 8 bits of the sector count register. We need it in both the standard and NCQ / FPDMA cases. sys/geom/eli/g_eli.c: Pass BIO_ZONE commands through the GELI class. sys/geom/geom.h: Add g_io_zonecmd() prototype. sys/geom/geom_dev.c: Add new DIOCZONECMD ioctl, which allows sending zone commands to disks. sys/geom/geom_disk.c: Add support for BIO_ZONE commands. sys/geom/geom_disk.h: Add a new flag, DISKFLAG_CANZONE, that indicates that a given GEOM disk client can handle BIO_ZONE commands. sys/geom/geom_io.c: Add a new function, g_io_zonecmd(), that handles execution of BIO_ZONE commands. Add permissions check for BIO_ZONE commands. Add command decoding for BIO_ZONE commands. sys/geom/geom_subr.c: Add DDB command decoding for BIO_ZONE commands. sys/kern/subr_devstat.c: Record statistics for REPORT ZONES commands. Note that the number of bytes transferred for REPORT ZONES won't quite match what is received from the harware. This is because we're necessarily counting bytes coming from the da(4) / ada(4) drivers, which are using the disk_zone.h interface to communicate up the stack. The structure sizes it uses are slightly different than the SCSI and ATA structure sizes. sys/sys/ata.h: Add many bit and structure definitions for ZAC, NCQ, and EPC command support. sys/sys/bio.h: Convert the bio_cmd field to a straight enumeration. This will yield more space for additional commands in the future. After change r297955 and other related changes, this is now possible. Converting to an enumeration will also prevent use as a bitmask in the future. sys/sys/disk.h: Define the DIOCZONECMD ioctl. sys/sys/disk_zone.h: Add a new API for managing zoned disks. This is very close to the SCSI ZBC and ATA ZAC standards, but uses integers in native byte order instead of big endian (SCSI) or little endian (ATA) byte arrays. This is intended to offer to the complete feature set of the ZBC and ZAC disk management without requiring the application developer to include SCSI or ATA headers. We also use one set of headers for ioctl consumers and kernel bio-level consumers. sys/sys/param.h: Bump __FreeBSD_version for sys/bio.h command changes, and inclusion of SMR support. usr.sbin/Makefile: Add the zonectl utility. usr.sbin/diskinfo/diskinfo.c Add disk zoning capability to the 'diskinfo -v' output. usr.sbin/zonectl/Makefile: Add zonectl makefile. usr.sbin/zonectl/zonectl.8 zonectl(8) man page. usr.sbin/zonectl/zonectl.c The zonectl(8) utility. This allows managing SCSI or ATA zoned disks via the disk_zone.h API. You can report zones, reset write pointers, get parameters, etc. Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D6147 Reviewed by: wblock (documentation)
2016-05-19 14:08:36 +00:00
/*cdb_storage*/ NULL,
/*cdb_storage_len*/ 0,
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
/*sense_len*/ SSD_FULL_SIZE,
/*timeout*/ timeout ? timeout : WB_TIMEOUT,
/*is48bit*/ 0,
/*devtype*/ devtype);
Add support for managing Shingled Magnetic Recording (SMR) drives. This change includes support for SCSI SMR drives (which conform to the Zoned Block Commands or ZBC spec) and ATA SMR drives (which conform to the Zoned ATA Command Set or ZAC spec) behind SAS expanders. This includes full management support through the GEOM BIO interface, and through a new userland utility, zonectl(8), and through camcontrol(8). This is now ready for filesystems to use to detect and manage zoned drives. (There is no work in progress that I know of to use this for ZFS or UFS, if anyone is interested, let me know and I may have some suggestions.) Also, improve ATA command passthrough and dispatch support, both via ATA and ATA passthrough over SCSI. Also, add support to camcontrol(8) for the ATA Extended Power Conditions feature set. You can now manage ATA device power states, and set various idle time thresholds for a drive to enter lower power states. Note that this change cannot be MFCed in full, because it depends on changes to the struct bio API that break compatilibity. In order to avoid breaking the stable API, only changes that don't touch or depend on the struct bio changes can be merged. For example, the camcontrol(8) changes don't depend on the new bio API, but zonectl(8) and the probe changes to the da(4) and ada(4) drivers do depend on it. Also note that the SMR changes have not yet been tested with an actual SCSI ZBC device, or a SCSI to ATA translation layer (SAT) that supports ZBC to ZAC translation. I have not yet gotten a suitable drive or SAT layer, so any testing help would be appreciated. These changes have been tested with Seagate Host Aware SATA drives attached to both SAS and SATA controllers. Also, I do not have any SATA Host Managed devices, and I suspect that it may take additional (hopefully minor) changes to support them. Thanks to Seagate for supplying the test hardware and answering questions. sbin/camcontrol/Makefile: Add epc.c and zone.c. sbin/camcontrol/camcontrol.8: Document the zone and epc subcommands. sbin/camcontrol/camcontrol.c: Add the zone and epc subcommands. Add auxiliary register support to build_ata_cmd(). Make sure to set the CAM_ATAIO_NEEDRESULT, CAM_ATAIO_DMA, and CAM_ATAIO_FPDMA flags as appropriate for ATA commands. Add a new get_ata_status() function to parse ATA result from SCSI sense descriptors (for ATA passthrough over SCSI) and ATA I/O requests. sbin/camcontrol/camcontrol.h: Update the build_ata_cmd() prototype Add get_ata_status(), zone(), and epc(). sbin/camcontrol/epc.c: Support for ATA Extended Power Conditions features. This includes support for all features documented in the ACS-4 Revision 12 specification from t13.org (dated February 18, 2016). The EPC feature set allows putting a drive into a power power mode immediately, or setting timeouts so that the drive will automatically enter progressively lower power states after various idle times. sbin/camcontrol/fwdownload.c: Update the firmware download code for the new build_ata_cmd() arguments. sbin/camcontrol/zone.c: Implement support for Shingled Magnetic Recording (SMR) drives via SCSI Zoned Block Commands (ZBC) and ATA Zoned Device ATA Command Set (ZAC). These specs were developed in concert, and are functionally identical. The primary differences are due to SCSI and ATA differences. (SCSI is big endian, ATA is little endian, for example.) This includes support for all commands defined in the ZBC and ZAC specs. sys/cam/ata/ata_all.c: Decode a number of additional ATA command names in ata_op_string(). Add a new CCB building function, ata_read_log(). Add ata_zac_mgmt_in() and ata_zac_mgmt_out() CCB building functions. These support both DMA and NCQ encapsulation. sys/cam/ata/ata_all.h: Add prototypes for ata_read_log(), ata_zac_mgmt_out(), and ata_zac_mgmt_in(). sys/cam/ata/ata_da.c: Revamp the ada(4) driver to support zoned devices. Add four new probe states to gather information needed for zone support. Add a new adasetflags() function to avoid duplication of large blocks of flag setting between the async handler and register functions. Add new sysctl variables that describe zone support and paramters. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. sys/cam/scsi/scsi_all.c: Add command descriptions for the ZBC IN/OUT commands. Add descriptions for ZBC Host Managed devices. Add a new function, scsi_ata_pass() to do ATA passthrough over SCSI. This will eventually replace scsi_ata_pass_16() -- it can create the 12, 16, and 32-byte variants of the ATA PASS-THROUGH command, and supports setting all of the registers defined as of SAT-4, Revision 5 (March 11, 2016). Change scsi_ata_identify() to use scsi_ata_pass() instead of scsi_ata_pass_16(). Add a new scsi_ata_read_log() function to facilitate reading ATA logs via SCSI. sys/cam/scsi/scsi_all.h: Add the new ATA PASS-THROUGH(32) command CDB. Add extended and variable CDB opcodes. Add Zoned Block Device Characteristics VPD page. Add ATA Return SCSI sense descriptor. Add prototypes for scsi_ata_read_log() and scsi_ata_pass(). sys/cam/scsi/scsi_da.c: Revamp the da(4) driver to support zoned devices. Add five new probe states, four of which are needed for ATA devices. Add five new sysctl variables that describe zone support and parameters. The da(4) driver supports SCSI ZBC devices, as well as ATA ZAC devices when they are attached via a SCSI to ATA Translation (SAT) layer. Since ZBC -> ZAC translation is a new feature in the T10 SAT-4 spec, most SATA drives will be supported via ATA commands sent via the SCSI ATA PASS-THROUGH command. The da(4) driver will prefer the ZBC interface, if it is available, for performance reasons, but will use the ATA PASS-THROUGH interface to the ZAC command set if the SAT layer doesn't support translation yet. As I mentioned above, ZBC command support is untested. Add support for the new BIO_ZONE bio, and all of its subcommands: DISK_ZONE_OPEN, DISK_ZONE_CLOSE, DISK_ZONE_FINISH, DISK_ZONE_RWP, DISK_ZONE_REPORT_ZONES, and DISK_ZONE_GET_PARAMS. Add scsi_zbc_in() and scsi_zbc_out() CCB building functions. Add scsi_ata_zac_mgmt_out() and scsi_ata_zac_mgmt_in() CCB/CDB building functions. Note that these have return values, unlike almost all other CCB building functions in CAM. The reason is that they can fail, depending upon the particular combination of input parameters. The primary failure case is if the user wants NCQ, but fails to specify additional CDB storage. NCQ requires using the 32-byte version of the SCSI ATA PASS-THROUGH command, and the current CAM CDB size is 16 bytes. sys/cam/scsi/scsi_da.h: Add ZBC IN and ZBC OUT CDBs and opcodes. Add SCSI Report Zones data structures. Add scsi_zbc_in(), scsi_zbc_out(), scsi_ata_zac_mgmt_out(), and scsi_ata_zac_mgmt_in() prototypes. sys/dev/ahci/ahci.c: Fix SEND / RECEIVE FPDMA QUEUED in the ahci(4) driver. ahci_setup_fis() previously set the top bits of the sector count register in the FIS to 0 for FPDMA commands. This is okay for read and write, because the PRIO field is in the only thing in those bits, and we don't implement that further up the stack. But, for SEND and RECEIVE FPDMA QUEUED, the subcommand is in that byte, so it needs to be transmitted to the drive. In ahci_setup_fis(), always set the the top 8 bits of the sector count register. We need it in both the standard and NCQ / FPDMA cases. sys/geom/eli/g_eli.c: Pass BIO_ZONE commands through the GELI class. sys/geom/geom.h: Add g_io_zonecmd() prototype. sys/geom/geom_dev.c: Add new DIOCZONECMD ioctl, which allows sending zone commands to disks. sys/geom/geom_disk.c: Add support for BIO_ZONE commands. sys/geom/geom_disk.h: Add a new flag, DISKFLAG_CANZONE, that indicates that a given GEOM disk client can handle BIO_ZONE commands. sys/geom/geom_io.c: Add a new function, g_io_zonecmd(), that handles execution of BIO_ZONE commands. Add permissions check for BIO_ZONE commands. Add command decoding for BIO_ZONE commands. sys/geom/geom_subr.c: Add DDB command decoding for BIO_ZONE commands. sys/kern/subr_devstat.c: Record statistics for REPORT ZONES commands. Note that the number of bytes transferred for REPORT ZONES won't quite match what is received from the harware. This is because we're necessarily counting bytes coming from the da(4) / ada(4) drivers, which are using the disk_zone.h interface to communicate up the stack. The structure sizes it uses are slightly different than the SCSI and ATA structure sizes. sys/sys/ata.h: Add many bit and structure definitions for ZAC, NCQ, and EPC command support. sys/sys/bio.h: Convert the bio_cmd field to a straight enumeration. This will yield more space for additional commands in the future. After change r297955 and other related changes, this is now possible. Converting to an enumeration will also prevent use as a bitmask in the future. sys/sys/disk.h: Define the DIOCZONECMD ioctl. sys/sys/disk_zone.h: Add a new API for managing zoned disks. This is very close to the SCSI ZBC and ATA ZAC standards, but uses integers in native byte order instead of big endian (SCSI) or little endian (ATA) byte arrays. This is intended to offer to the complete feature set of the ZBC and ZAC disk management without requiring the application developer to include SCSI or ATA headers. We also use one set of headers for ioctl consumers and kernel bio-level consumers. sys/sys/param.h: Bump __FreeBSD_version for sys/bio.h command changes, and inclusion of SMR support. usr.sbin/Makefile: Add the zonectl utility. usr.sbin/diskinfo/diskinfo.c Add disk zoning capability to the 'diskinfo -v' output. usr.sbin/zonectl/Makefile: Add zonectl makefile. usr.sbin/zonectl/zonectl.8 zonectl(8) man page. usr.sbin/zonectl/zonectl.c The zonectl(8) utility. This allows managing SCSI or ATA zoned disks via the disk_zone.h API. You can report zones, reset write pointers, get parameters, etc. Sponsored by: Spectra Logic Differential Revision: https://reviews.freebsd.org/D6147 Reviewed by: wblock (documentation)
2016-05-19 14:08:36 +00:00
if (retval != 0) {
warnx("%s: build_ata_cmd() failed, likely "
"programmer error", __func__);
goto bailout;
}
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
break;
}
default:
warnx("Unknown device type %d", devtype);
retval = 1;
goto bailout;
break; /*NOTREACHED*/
Update the 'fwdownload' command to also flash disks connected over an ATA/SATA transport. The detection logic is automatic, so it should Just Work. While here, also improve the progress meter that is displayed during firmware download. Submitted by: Alistair Crooks Obtained from: Netflix, Inc. MFC after: 3 days
2012-06-20 00:17:29 +00:00
}
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
if (!sim_mode) {
/* Execute the command. */
Improve firmware download status check. Previous check was insufficient for ATA since it ignored transport errors like command timeouts, while for SCSI it was just wrong.
2013-06-14 08:26:58 +00:00
if (cam_send_ccb(cam_dev, ccb) < 0 ||
(ccb->ccb_h.status & CAM_STATUS_MASK) !=
CAM_REQ_CMP) {
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
warnx("Error writing image to device");
More -Wmissing-variable-declarations fixes. In addition to adding `static' where possible: - bin/date: Move `retval' into extern.h to make it visible to date.c. - bin/ed: Move globally used variables into ed.h. - sbin/camcontrol: Move `verbose' into camcontrol.h and fix shadow warnings. - usr.bin/calendar: Remove unneeded variables. - usr.bin/chat: Make `line' local instead of global. - usr.bin/elfdump: Comment out unneeded function. - usr.bin/rlogin: Use _Noreturn instead of __dead2. - usr.bin/tset: Pull `Ospeed' into extern.h. - usr.sbin/mfiutil: Put global variables in mfiutil.h. - usr.sbin/pkg: Remove unused `os_corres'. - usr.sbin/quotaon, usr.sbin/repquota: Remove unused `qfname'.
2012-10-19 14:49:42 +00:00
if (printerrors)
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
cam_error_print(cam_dev, ccb,
CAM_ESF_ALL, CAM_EPF_ALL, stderr);
retval = 1;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
goto bailout;
}
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
} else if (printerrors) {
cam_error_print(cam_dev, ccb, CAM_ESF_COMMAND, 0,
stdout);
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
}
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
/* Prepare next round. */
pkt_count++;
pkt_ptr += pkt_size;
img_size -= pkt_size;
} while(!last_pkt);
bailout:
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
if (quiet == 0)
progress_complete(&progress, size - img_size);
Fix memory leaks in camcontrol Reported by: Coverity CID: 1331674, 1331675 Reviewed by: ken MFC after: 3 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D10588
2017-05-03 19:56:55 +00:00
cam_freeccb(ccb);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
return (retval);
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
}
int
fwdownload(struct cam_device *device, int argc, char **argv,
Add task attribute support to camcontrol(8). Users can use the new generic argument, -Q task_attr, to specify a task attribute (simple, ordered, head of queue, aca) for the commands issued. The the default is simple, which works with all SCSI devices that support tagged queueing. This will mostly be useful for debugging target behavior in certain situations. You can try it out by compiling CTL with CTL_IO_DELAY turned on (in sys/cam/ctl/ctl_io.h) and then do something like this with one of the CTL LUNs: ctladm delay 0:0 -l done -t 10 camcontrol tur da34 -v And at then before the 10 second timer is up, in another terminal: camcontrol inquiry da34 -Q ordered -v The Inquiry should complete just after the TUR completes. Ordinarily it would complete first because of the delay injection, but because the task attribute is set to ordered in this case, CTL holds it up until the previous command has completed. sbin/camcontrol/camcontrol.c: Add the new generic argument, -Q, which allows the user to specify a SCSI task attribute. The user can specify task attributes by name or numerically. Add a new task_attr arguments to SCSI sub-functions. sbin/camcontrol/attrib.c, sbin/camcontrol/camcontrol.h, sbin/camcontrol/fwdownload.c, sbin/camcontrol/modeedit.c, sbin/camcontrol/persist.c, sbin/camcontrol/timestamp.c, sbin/camcontrol/zone.c: Add the new task_attr argument to SCSI sub-functions. sbin/camcontrol/camcontrol.8: Document the new -Q option, and add an example. Sponsored by: Spectra Logic MFC after: 1 week
2017-02-17 20:04:22 +00:00
char *combinedopt, int printerrors, int task_attr, int retry_count,
int timeout)
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
{
Fix memory leaks in camcontrol Reported by: Coverity CID: 1331674, 1331675 Reviewed by: ken MFC after: 3 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D10588
2017-05-03 19:56:55 +00:00
union ccb *ccb = NULL;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
struct fw_vendor *vp;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
char *fw_img_path = NULL;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
struct ata_params *ident_buf = NULL;
camcontrol_devtype devtype;
char *buf = NULL;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
int img_size;
int c;
int sim_mode = 0;
int confirmed = 0;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
int quiet = 0;
int retval = 0;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
while ((c = getopt(argc, argv, combinedopt)) != -1) {
switch (c) {
case 'f':
fw_img_path = optarg;
break;
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
case 'q':
quiet = 1;
break;
case 's':
sim_mode = 1;
break;
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
case 'y':
confirmed = 1;
break;
default:
break;
}
}
if (fw_img_path == NULL)
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
errx(1, "you must specify a firmware image file using -f "
"option");
retval = get_device_type(device, retry_count, timeout, printerrors,
&devtype);
if (retval != 0)
errx(1, "Unable to determine device type");
if ((devtype == CC_DT_ATA)
Use the more proper term of SATL instead of ATA_BEHIND_SCSI. Most people know SAS attached SATA devices by the name SAT or SATL (with the latter being a little more common). Change the device type ATA_BEHIND_SCSI to SATL since it's more specific and meaningful. Suggested by: scottl@
2019-07-15 20:25:41 +00:00
|| (devtype == CC_DT_SATL)) {
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
ccb = cam_getccb(device);
if (ccb == NULL) {
warnx("couldn't allocate CCB");
retval = 1;
goto bailout;
}
if (ata_do_identify(device, retry_count, timeout, ccb,
&ident_buf) != 0) {
retval = 1;
goto bailout;
}
} else if (devtype != CC_DT_SCSI)
errx(1, "Unsupported device type %d", devtype);
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
vp = fw_get_vendor(device, ident_buf);
/*
* Bail out if we have an unknown vendor and this isn't an ATA
* disk. For a SCSI disk, we have no chance of working properly
* with the default values in the VENDOR_UNKNOWN case. For an ATA
* disk connected via an ATA transport, we may work for drives that
* support the ATA_DOWNLOAD_MICROCODE command.
*/
if (((vp == NULL)
|| (vp->type == VENDOR_UNKNOWN))
&& (devtype == CC_DT_SCSI))
errx(1, "Unsupported device");
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
Add task attribute support to camcontrol(8). Users can use the new generic argument, -Q task_attr, to specify a task attribute (simple, ordered, head of queue, aca) for the commands issued. The the default is simple, which works with all SCSI devices that support tagged queueing. This will mostly be useful for debugging target behavior in certain situations. You can try it out by compiling CTL with CTL_IO_DELAY turned on (in sys/cam/ctl/ctl_io.h) and then do something like this with one of the CTL LUNs: ctladm delay 0:0 -l done -t 10 camcontrol tur da34 -v And at then before the 10 second timer is up, in another terminal: camcontrol inquiry da34 -Q ordered -v The Inquiry should complete just after the TUR completes. Ordinarily it would complete first because of the delay injection, but because the task attribute is set to ordered in this case, CTL holds it up until the previous command has completed. sbin/camcontrol/camcontrol.c: Add the new generic argument, -Q, which allows the user to specify a SCSI task attribute. The user can specify task attributes by name or numerically. Add a new task_attr arguments to SCSI sub-functions. sbin/camcontrol/attrib.c, sbin/camcontrol/camcontrol.h, sbin/camcontrol/fwdownload.c, sbin/camcontrol/modeedit.c, sbin/camcontrol/persist.c, sbin/camcontrol/timestamp.c, sbin/camcontrol/zone.c: Add the new task_attr argument to SCSI sub-functions. sbin/camcontrol/camcontrol.8: Document the new -Q option, and add an example. Sponsored by: Spectra Logic MFC after: 1 week
2017-02-17 20:04:22 +00:00
retval = fw_get_timeout(device, vp, task_attr, retry_count, timeout);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
if (retval != 0) {
warnx("Unable to get a firmware download timeout value");
goto bailout;
}
buf = fw_read_img(device, retry_count, timeout, quiet, fw_img_path,
vp, &img_size);
if (buf == NULL) {
retval = 1;
goto bailout;
}
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
if (!confirmed) {
fprintf(stdout, "You are about to download firmware image (%s)"
" into the following device:\n",
fw_img_path);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
if (devtype == CC_DT_SCSI) {
Add task attribute support to camcontrol(8). Users can use the new generic argument, -Q task_attr, to specify a task attribute (simple, ordered, head of queue, aca) for the commands issued. The the default is simple, which works with all SCSI devices that support tagged queueing. This will mostly be useful for debugging target behavior in certain situations. You can try it out by compiling CTL with CTL_IO_DELAY turned on (in sys/cam/ctl/ctl_io.h) and then do something like this with one of the CTL LUNs: ctladm delay 0:0 -l done -t 10 camcontrol tur da34 -v And at then before the 10 second timer is up, in another terminal: camcontrol inquiry da34 -Q ordered -v The Inquiry should complete just after the TUR completes. Ordinarily it would complete first because of the delay injection, but because the task attribute is set to ordered in this case, CTL holds it up until the previous command has completed. sbin/camcontrol/camcontrol.c: Add the new generic argument, -Q, which allows the user to specify a SCSI task attribute. The user can specify task attributes by name or numerically. Add a new task_attr arguments to SCSI sub-functions. sbin/camcontrol/attrib.c, sbin/camcontrol/camcontrol.h, sbin/camcontrol/fwdownload.c, sbin/camcontrol/modeedit.c, sbin/camcontrol/persist.c, sbin/camcontrol/timestamp.c, sbin/camcontrol/zone.c: Add the new task_attr argument to SCSI sub-functions. sbin/camcontrol/camcontrol.8: Document the new -Q option, and add an example. Sponsored by: Spectra Logic MFC after: 1 week
2017-02-17 20:04:22 +00:00
if (scsidoinquiry(device, argc, argv, combinedopt,
MSG_SIMPLE_Q_TAG, 0, 5000) != 0) {
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
warnx("Error sending inquiry");
retval = 1;
goto bailout;
}
} else {
printf("%s%d: ", device->device_name,
device->dev_unit_num);
ata_print_ident(ident_buf);
camxferrate(device);
free(ident_buf);
}
fprintf(stdout, "Using a timeout of %u ms, which is %s.\n",
vp->timeout_ms,
fw_timeout_desc_table[vp->timeout_type].timeout_desc);
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
fprintf(stdout, "\nIt may damage your drive. ");
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
if (!get_confirmation()) {
retval = 1;
goto bailout;
}
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
}
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
if ((sim_mode != 0) && (quiet == 0))
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
fprintf(stdout, "Running in simulation mode\n");
More -Wmissing-variable-declarations fixes. In addition to adding `static' where possible: - bin/date: Move `retval' into extern.h to make it visible to date.c. - bin/ed: Move globally used variables into ed.h. - sbin/camcontrol: Move `verbose' into camcontrol.h and fix shadow warnings. - usr.bin/calendar: Remove unneeded variables. - usr.bin/chat: Make `line' local instead of global. - usr.bin/elfdump: Comment out unneeded function. - usr.bin/rlogin: Use _Noreturn instead of __dead2. - usr.bin/tset: Pull `Ospeed' into extern.h. - usr.sbin/mfiutil: Put global variables in mfiutil.h. - usr.sbin/pkg: Remove unused `os_corres'. - usr.sbin/quotaon, usr.sbin/repquota: Remove unused `qfname'.
2012-10-19 14:49:42 +00:00
if (fw_download_img(device, vp, buf, img_size, sim_mode, printerrors,
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
quiet, retry_count, vp->timeout_ms, fw_img_path, devtype) != 0) {
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
fprintf(stderr, "Firmware download failed\n");
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
retval = 1;
goto bailout;
} else if (quiet == 0)
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
fprintf(stdout, "Firmware download successful\n");
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
bailout:
Fix memory leaks in camcontrol Reported by: Coverity CID: 1331674, 1331675 Reviewed by: ken MFC after: 3 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D10588
2017-05-03 19:56:55 +00:00
cam_freeccb(ccb);
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
free(buf);
Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week
2015-08-20 16:07:51 +00:00
return (retval);
Add firmware update support for SCSI devices. Firmware can be reprogrammed on devices from Hitachi, HP, IBM, Plextor, Quantum, and Seagate. At least one device from each manufacturer has been tested with some version of this code, and it has been used to update thousands of drives so far. The man page suggests having a backup of the drive's data, and the operation must be confirmed, either interactively or on the command line. (This is the same as the confirmation on the format command.) This work is largely derived from fwprog.c by Andre Albsmeier. Submitted by: Nima Misaghian Sponsored by: Sandvine Incorporated MFC after: 3 months
2011-11-25 04:03:37 +00:00
}
Reference in New Issue Copy Permalink