Changing model number so array recognizes non-OEM disk

[twwlogin]

Hi. I have a Sun StorageTek 6140 array with 32 Sun ST3300007FC drives. Sun rebrands them and seems to have changed the model number on the drives so the array limits recognition to the Sun drives. I've added a new shelf for an additional 16 Seagate ST3300007FC drives and went the cheap route with HP-rebranded ST3300007FC drives. Of course, the array doesn't recognize the drives. The latest Sun firmware for these drives is 055A. Sun ships the firmware for these drives as a D_ST330000FSUN300G_055A.dlp file. I think the format of this file is similar to what HP uses with a .df extension (http://hardforum.com/showthread.php?t=1660270).

Code:

0000000: 4472 6976 655f 446f 776e 6c6f 6164 5f46 696c 655f 4865 6164 6572 0000 0000 0000 01  Drive_Download_File_Header.......
0000021: 0000 00b8 0000 0050 d909 00cd 0306 0953 6561 6761 7465 0000 0000 0000 0000 0053 54  .......P.......Seagate.........ST
0000042: 3333 3030 3030 4653 554e 3330 3047 0000 0000 0000 0000 0000 0000 0000 0000 0000 00  330000FSUN300G...................
0000063: 0000 0000 0030 3535 4100 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 00  .....055A........................
0000084: 0000 0000 0000 0000 0000 0000 0000 0000 0400 0000 3032 3532 0000 0000 3033 3534 00  ....................0252....0354.
00000a5: 0000 0030 3435 3800 0000 0030 3535 4100 0000 0041 6374 696f 6e5f 4465 7363 7269 70  ...0458....055A....Action_Descrip
00000c6: 746f 7200 0000 0000 0000 0000 0000 0000 0000 0100 0000 9800 0000 0000 0000 0000 00  tor..............................
00000e7: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0003 0000 0000 d809 00  .................................
0000108: 0000 0000 0a00 0000 3b05 0000 0000 09d8 0000 0000 0000 0000 0000 0000 0000 0000 00  ........;........................
0000129: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00  .................................
000014a: 0000 0000 0000 00d8 0900 0000 0000 0000 0000 0000 6700 c003 0000 0000 0000 0000 00  ....................g............
000016b: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00  .................................
000018c: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00  .................................
00001ad: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00  .................................
00001ce: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00  .................................
00001ef: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00  .................................


Is there a tool I could use to change the model number of this drive to "ST330000FSUN300G"? I think if I do this, I can use the array software to replace the firmware. The big issue is getting the drive recognized and I think the solution to this is changing the model number.

[fzabkar]

Could you provide a link to the firmware? I probably won't be able to help you, but I'd like to examine the structure of the update. FWIW, I've done similar work for Seagate, WD, and Samsung SATA drives.

[twwlogin]

http://files.hddguru.com/download/SCSI/Firmware/StorageTek/D_ST330000FSUN300G_055A.dlp

[fzabkar]

The firmware structure doesn't look like any Seagate examples that I've analysed. The MCU appears to be based on an Intel 8096 core rather than ARM. Other update packages are comprised of several modules, including the PCB ROM and some SA modules, typically overlays. The latter are located on the platters. Unfortunately I don't have a resource dump for comparison purposes, so I'm finding it difficult to identify the individual components in the DLP file. Normally it would be a bad idea to update a retail drive with OEM firmware, because you cannot be certain whether the updated modules are compatible with the existing ones. However, knowing which parts are targeted by the update may help to minimise the risk.

I notice that the code contains the text string, "SER NUM MISMATCH". This would suggest that the ROM on the PCB may be modular, ie it may contain a mix of code plus unique, drive specific data. If so, then that would make it even harder to extract the ROM sections from the DLP file.

That said, there is sometimes a method, at least in SATA drives, where an update may be "forcibly" applied. However, such a method would depend on the tool that is used to apply the update (eg SeaFlash or SeaTools Enterprise version, or something else). Was Sun's package shipped with any such tool, or do you have a link to a Dell or HP update package for the same drive?

[Dmitri]

Hi. I have a Sun StorageTek 6140 array with 32 Sun ST3300007FC drives.
...
Is there a tool I could use to change the model number of this drive to "ST330000FSUN300G"? I think if I do this, I can use the array software to replace the firmware. The big issue is getting the drive recognized and I think the solution to this is changing the model number.

Unfortunately, chances of this approach to work are slim to none.

[twwlogin]

With the help of someone on the #openindiana IRC list, I was able to separate the Seagate firmware from the Sun D_ST330000FSUN300G_055A.dlp firmware file. I tried to flash the firmware to an HP-branded Seagate ST3300007FC drive but was unsuccessful:

Code:

# fwflash -l
...
Device[5]                       /devices/pci@0,0/pci8086,340e@7/pci1077,143@0/fp@0,0/disk@w21000014c3c7ea96,0:c,raw
  Class [sd]                    /dev/rdsk/c12t64d0s2
        Vendor                  : HPQ
        Product                 : BD30058232
        Firmware revision       : HP05
        Inquiry Serial Number   : 3KR26YVR00007645FP00
        GUID                    : (not supported)

# fwflash -f /var/tmp/055A.lod -d /devices/pci@0,0/pci8086,340e@7/pci1077,143@0/fp@0,0/disk@w21000014c3c7ea96,0:c,raw
About to update firmware on /devices/pci@0,0/pci8086,340e@7/pci1077,143@0/fp@0,0/disk@w21000014c3c7ea96,0:c,raw
with file /var/tmp/055A.lod.
Do you want to continue? (Y/N): Y
fwflash: RETURN STATUS: Status: CHECK CONDITION
fwflash: Failed to flash firmware file /var/tmp/055A.lod on device /devices/pci@0,0/pci8086,340e@7/pci1077,143@0/fp@0,0/disk@w21000014c3c7ea96,0:c,raw: 1

# /var/tmp/fwdl /dev/rdsk/c12t64d0s2 /var/tmp/055A.lod
Sense data: (18 bytes)
        70 00 05 00 00 00 00 0a 00 00 00 00 24 00 01 cc
        00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       
--------------------------------------------------------
Check Condition
Failed to get inquiry data.
Gathering inquiry data from the drive...


Any idea what the above error means?

[guru]

Send those drives back and get a refund...quick!

[twwlogin]

And I tried the Linux fwdl utility:

Code:

# fdisk -l
...
Disk /dev/sdb: 300.0 GB, 300000000000 bytes
255 heads, 63 sectors/track, 36472 cylinders, total 585937500 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x20202020

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *       16065   585922679   292953307+  bf  Solaris
...

# fwdl /dev/sdb 055A.lod
handleSCSIcmd: read status = 0x24, result = 0x3f800004
handleSCSIcmd: read sense c3 10 e2 f6 bd 7b 7 8b e 13 0 e9 eb 0 b4 0
TestUnitReady failed
The drive is not ready to accept the firmware.


[twwlogin]

I bought 11 of the drives. I'm shipping them back today. Let me try some more of them.

Does the sense data I posted indicate a problem with the drives? They were suppose to be new drives, though HP-branded.

[guru]

Seagate Entetprise HDDs have firmware OEM lock. No way to change firmware types safely

[Dmitri]

I was able to separate the Seagate firmware from the Sun D_ST330000FSUN300G_055A.dlp firmware file. I tried to flash the firmware to an HP-branded Seagate ST3300007FC drive but was unsuccessful:
...
Any idea what the above error means?

We have played with Seagate drives some time ago, converting few of them from generic to OEM ones and vice versa, changed between different OEMs as well. But the process is a real PITA and it's not always possible to replace the firmware, as even modules structure can be different, so it is quite easy to put the drive into a coma.

SENSE 5-24-00 is from the "invalid parameter" series.
Firmware and loader contain unique ids, which are obviously different for HP and Sun, so just uploading the firmware isn't an option.

Moreover, even if you'll find a rather tricky way to patch the loader, there's another level of protection, which will prevent the upload. Besides all that drive lock mechanism adds some extra fun to the process to make sure that after failure researcher will have to dig through the SA manually to revive the drive.