Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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/
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |