MFC, r286965:

MFC, r286965:

  ------------------------------------------------------------------------
  r286965 | ken | 2015-08-20 10:07:51 -0600 (Thu, 20 Aug 2015) | 297 lines

  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

git-svn-id: svn://svn.freebsd.org/base/stable/10@287203 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f