Hello everyone,

I recently bought some DELL branded SAS disks (ST2000NM0023) for my homelab, but one arrived defective. Since I also wanted to tinker around with custom firmware (in the hopes of enabling some DELL disabled features (?) I used the defective one as a sort of guinea pig. Tried flashing the DELL lod to it without removing the DELL header, big mistake. But my overall goal still stands. I want to be able to reflash these DELL disks to retail ones. I hooked up a flash programmer to a second disk and read out the flash successfully, and I'm currently trying to make sense of it all.

The firmware from the Disk seems to have two headers at the beginning, which is the first thing I don't understand. I've tried mapping out the different areas. From my understanding, the Offsets apply from the beginning of the current header, correct?

What I now want to do is to be able to use the stock Seagate LOD and use the correct bits and pieces to create a rom that will fit on the SPI flash and also work. From what I can tell this is not an F3 disk (although I am not sure as I can't find that much information on the topic), so some of the tools don't work or throw errors. I don't know if I am allowed to attack a the Seagate LOD or even the DELL ROM dump so I'll leave it until someone tells me otherwise

Is there anyone here who has done anything similar already? Just so I know. I think one of the main issues is that the drives are all currently on GE09 and I cannot find that firmware anywhere to download, so there's no way for me to compare the LOD to the actual contents of the flash. One thing I have notices is that the flash chip seems to be virtually empty after approx. 512 bytes, with only occasional blocks of zeroes.

Tool for explore ROM:
https://yadi.sk/d/uCjFT6nUhr_-Qw
Tool for edit loader:
https://yadi.sk/d/7HwS4BBh3Vj0Bg
Megalodon E007 aka "stock" firmware:
https://yadi.sk/d/zli2OX1e7Hbm6A
Factory loader may not flash DELL disks. Then "refinement" is required.

Thank you very much for your response!

So what you're suggesting is that I modify the stock loader (the .lod file?) with bits from the ROM (the SPI flash dump?) so that the disk accepts it via normal seaflash_firmware flash?

The disks themselves can be flashed by seaflash as I managed to procure a copy of the DELL GE0F firmware for them and it flashed fine with it.

Add to previous post:

The factory LOD indeed will not flash on the DELL disk, if that's what you meant. Sorry, I must have mixed up the flash utility with loader.

I think the factory .lod file checks for compatible firmware IDs. What's interesting to me though is that I was able to send the DELL .fwh with the DELL header (which you obviously shouldn't do) WITHOUT it performing any check, thus bricking the experimental disk.

So I think that the factory Seagate .lod is check for firmware versions and because mine is GE09 (well it used to be, now it is GE0F) it refuses to flash.

Seaflash has several command line options. It can either use an explicit family, model and file name, or it can consult a configuration file.

Sflash.exe internal docs:
http://www.users.on.net/~fzabkar/sf_usage.txt

The configuration file is usually encrypted, but I have written a decrypting tool for the earlier versions:
http://www.hddoracle.com/download/file.php?id=3698

Sample file (decrypted):
http://www.users.on.net/~fzabkar/dell_fw_cfg.txt

The file's structure is explained in the SeaChest docs:
http://support.seagate.com/seachest/SeaChest_Combo_UserGuides.html

Decoding Seagate firmware update configuration files:
http://www.hddoracle.com/viewtopic.php?f=22&t=1820

_________________
A backup a day keeps DR away.

Your posts are what I base most of my (limited) knowledge on!

Yes I saw the configuration file thread, the thing is that the archive doesn't include one, unfortunately!

If I understand those docs correctly, I should be able to create my own...?

Edit: But I should also be able to tell seaflash to flash the firmware to the disk by using the command line options you mentioned?

I can only speak about SATA updates, but I would expect there to be a BAT file which contains a SeaFlash command line. That should tell you what the updater is looking for. Dell's fwh header also has some information regarding the payload components.

Can you upload the update package?

BTW, it is usually a bad idea to cross-flash between OEM and retail firmware versions. The update package usually contains ROM segments and SA overlays, so it does not completely overwrite the existing firmware. This means that the new components may not necessarily be compatible with the existing ones. In fact I have seen people brick their drives by doing what you are trying to do.

_________________
A backup a day keeps DR away.

Oh I am aware that I could brick it, that's why I used a drive with a defective motor to experiment on first

If that works the way I want it to I can test it on another drive that works and if it bricks it, so be it. It's mostly just to see if it could be done honestly, and maybe someone could get some use out of the information I could find.

Sure, I'll upload the Seagate one as I downloaded it from them, a DELL update package for the same drive and I'll also attach the ROM dump I took of the SPI flash on the drive. I've also attached the DELL firmware (GE0F.lod) that was so hard to come by, maybe it can be useful for someone!

I've also noticed that F3Romexplorer gives me some checksum/crc errors when opening the rom dump and LODedit does the same when I open the lod.

As you say, there is no BAT or CFS file to control the firmware download. The Dell payload has a 0x100 byte header which must be stripped off to convert it to LOD format for SeaTools or SeaChest.

You can use @E123's tools to parse the LOD files and the ROM dump. The ROM CRC errors are probably OK -- even working ROMs have these errors. I think Seagate's programmers are just sloppy. Just to be sure, you should dump the ROM several times and compare the dumps. You also need to be mindful of the ROM's Vcc. The latest drives use 1.8V ROMs. Earlier ones could be 2.5V or 3.3V. You can verify the Vcc (pin #8) by measuring it.

_________________
A backup a day keeps DR away.

You can ignore CRC errors in ROM. For some modules, the CRC is not provided. For others - the flasher when updating the firmware did not count the CRC. So it is not checked when loading by the disk itself. If the disk spins platters - 100% all the necessary CRC are correct.
Now about the updates. On Seagate, I have not yet encountered a vendor-dependent "hardware". But there is a mechanism for checking the compatibility of updates. It is located inside the disk firmware.
If the "stock" firmware is not load into the OEM disk, or vice versa, then you need to disable the verification mechanism inside the disk. Or correct the loader so that it passes the "friend or foe" test.
On SATA, it was possible to do without editing the code.
On SAS in both cases it is necessary to make changes to the code.
But I do not exclude that there is a simpler mechanism.
If the firmware signed, you 99.999% do nothing.

@fzabkar I've dumped the ROM multiple times, no differences in the dumps (I wanted to be sure as well) also I lucked out and the flash is 3.3v, I am able to read and write to it just fine.
Yeah I can remove the DELL header but it won't flash since it doesn't pass verification. Just one thing baffles me: how come I cannot flash the ROM with the DELL header removed, aka, a proper lod, but the disk accepted the ROM WITH the Dell header, therefor bricking itself? I read out the SPI and the DELL header was included! For all intents and purposes, it shouldn't have worked. I read out the ROM of a second drive (the one I attached) and surprise! no DELL header so I definitely know it's not intended.

@E123 Ahhh that's good to know then! Do you have any ideas about how I could correct the loader? As I said to @fzabkar for some reason the disk let me write garbage data to it before , albeit using the fwupload command of my LSI HBA, so not actually using seachest or anything. I guess it's similar to ATA flashing? I have tried this again with the normal loader but this time it would not allow me to do it for some reason.

Would it not be possible to use the ROM dump I have, combine it with modules from the LOD and then write it back to the disk with the SPI flasher? I don't think the firmware is signed to be honest, I think the F3 programs you linkes shouldn't have worked if that was the case.

EDIT: I guess one way to get rid of the verification mechanism could be to edit the official DELL GE0F loader, then flash that one, since the disk will accept it, and then flash the Seagate one?

The code you need, that checks the downloaded content, is on the platters. Get it, disassemble and determine what your disk expects. And... for this it is not at all necessary to be able to read the service area. You can search for a loader with the same version of the f/w as on your disk.
I already gave you a fishing rod. Believe me, you have everything in order not to remain hungry.

I've been looking around for a few hours now but I can't figure out how to dump the ROM contents from the platters. Wouldn't I need a TTL connection to the processor on the disk's motherboard for that? Unfortunately, that's not an option as I don't have an external SAS to USB adapter, only the drive bays in my server. I've also been looking into reading the service area, also none the wiser. I suspect I need Direct I/O access to read that code from the disk?

I've extracted all the sections from my rom dump and the loader though, so that's something. I was actually doing it manually, until I saw your tools you made

I should probably clarify that my main goal (besides just pure experimentation) is to enable APM and other disabled features on the drive. If there's another easier way, do let me know

Would that be possible over TTL for example?

I've also just tried to flash one of the drives with SeaTools on Windows and it says in green text "Firmware download: Pass!" but the firmware didn't actually update

Each of the overlays has a header which contains the build date/time stamp. Perhaps that is what the SAS firmware is baulking at?

_________________
A backup a day keeps DR away.

I can definitely recognise the build string in the stock firmware (E007, same as FW version) whereas the dell one uses a different one (E80F, different from fw version)

Thank you and I'll check it out more!

The E8 is consistant between both DELL fw's I have, the second byte, 0F and 09 respectively seem to line up with the numbers in the FW revision 0F is from the GE0F firmware and 09 from the GE09

These are the headers for overlay 05h.

MegalodonES3-SAS-STD-E007.LOD


GE0F.lod

Seagate_Megalodon_GS15.fwh

This is what I have managed to find out about the header structure:

_________________
A backup a day keeps DR away.