[Discuss] updating hard drive firmware from a VM

[Tom Metro]

A drive burn-in turned up a pile of bad blocks reported by the badblocks
command, yet weren't showing up in the drive's SMART output.
SmartMonTools produced a warning alerting me that this particular drive
model could be impacted by this bug:
http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks

which fits the symptoms.

The manufacturer, Samsung (now Seagate), provides an MS DOS executable
that bundles the firmware blob and the loader. It's left as an exercise
for the user to find a bootable DOS environment. (Apparently for its own
products, Seagate provides its firmware tools bundled with bootable disk
images.)

Adding a complication is that the documentation for the firmware tool
says you need to install the drive you want to update as the primary
drive in the system. Not so easy to pull off if you are doing your drive
prep with a laptop, and the target drive is a 3.5" desktop drive.

I figured it would be a long shot that there was any sort of native
Linux support for loading hard drive firmware, which is undoubtedly
manufacturer-specific. But googling for that turned up this description:
http://unix.stackexchange.com/questions/1920/how-to-flash-firmware-under-linux-in-practice/43988

for how to create a FreeDOS bootable image file, integrate your firmware
tools, and then reconfigure your grub to boot from the image file on
your hard drive. (Not sure why this would be any easier than just
sticking the image on a USB Flash drive or CD.)

What I'm wondering is whether this sort of FreeDOS image could be booted
(as an emulated floppy or CD) in a VM (VirtualBox), which would be
configured to pass through the target disk as its primary drive.

Anyone tried something like this?

Will the VM adequately "get out of the way" enough to pass IDE commands
to the drive, if configured as a "raw" device?


Of course all this could have been avoided if the industry had a
standard IDE command for loading firmware. Then I could just get the
firmware blob from Samsung and using something like hdparm to load it on
my chosen device.

Oh wait, maybe they did...

% hdparm |& fgrep firm
 --fwdownload            Download firmware file to drive (EXTREMELY
DANGEROUS)
 --fwdownload-mode3      Download firmware using min-size segments
(EXTREMELY DANGEROUS)
 --fwdownload-mode3-max  Download firmware using max-size segments
(EXTREMELY DANGEROUS)
 --fwdownload-mode7      Download firmware using a single segment
(EXTREMELY DANGEROUS)

In the man page:
  --fwdownload
      When used, this should be the only option given.  It requires a
      file path immediately after the option, indicating where the new
      drive firmware should be read from.  The contents of this file
      will be sent to the drive using the (S)ATA DOWNLOAD MICROCODE
      command, using either transfer protocol 7 (entire file at
      once), or, if the drive supports it,  transfer  protocol  3
      (segmented  download). This command is EXTREMELY DANGEROUS and
      could destroy both the drive and all data on it.  DO NOT USE THIS
      COMMAND.  The --fwdownload-mode3 , --fwdownload-mode3-max , and
      --fwdownload-mode7 variations on  basic  --fwdownload allow
      overriding  automatic  protocol detection in favour of forcing
      hdparm to use a specific transfer protocol, for testing purposes
      only.

Well that sounds safe. :-)

Even if I wanted to try it, I'd first need to separate the firmware blob
from the firmware loader. The provided file does not appear to be a
self-extracting zip file. I don't exactly want to be guessing at where
the loader ends and where the firmware data starts, and send bogus code
to the drive.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/