This is a summary of my failed attempt at extracting .fluf firmware for the WD PC SN740 from Dell’s EXE. I can’t find the firmware for the SN740 anywhere else, and it seems to experience the same fail-to-wake-from-suspend issues that other WD SN* drives suffer from, and that is fixed by a firmware update.
Be angry at Framework. No really, this is an OEM drive that WD expects them to provide support for, and they don’t.
unzip WD-SN740-Solid-State-Drive-Firmware-Update_P5C6P_WIN64_7391.4108_A03.EXE, you get:
mup.xml, UTF-8 encoded metadata about the firmware package
package.xml, UTF-16LE encoded (different) metadata about the firmware package with no byte-order marker, which is just rude
WD73914108.exe, the good stuff lies inside
7z x WD73914108.exe, you get:
.data, .reloc, .rsrc, etc… stuff from the actual binary, don’t care
CERTIFICATE I think this is where the windows “this program is by this publisher” cert is stored but whatever
[0] this is where the good stuff is, but it’s in a bizzaro format archive.
At the end of [0] we can see YEXTPACKBIN DIRECTORY SIGNATURE which has no google results. about 4000 bytes before that we see
All numbers are little-endian. 02000000 means there are two files in this yextpackbin. The next 16 bytes are the name of the file, and the next 8 is the size of that file. Repeat for two files.
fwconfig is a file 259 bytes long (03 01 00 00 00 00 00 00)
bin0 is a file 2,805,760 bytes long (00 d0 2a 00 00 00 00 00)
Thus to extract bin0:
cat '[0]' | tail -c+260 | head -c2805760 > the_firmware.fluf
We can approximate that this is right by comparing to a known-good FLUF file (like this one for the SN770) and see that they both start and end the same way.
less 731120WD.fluf:
less the_firmware.fluf:
And then flash it! (this is where the disappointment comes)
# nvme fw-download -f the_firmware_maybe.fluf /dev/disk/by-id/nvme-WD_PC_SN740_yougettheidea
Firmware download success
# sudo nvme fw-commit -a 3 -s 2 /dev/disk/by-id/nvme-WD_PC_SN740_yougettheidea
NVMe status: Firmware Activation Prohibited: The image specified is being prohibited from activation by the controller for vendor specific reasons(0x4113)
Hopefully this is useful to someone. Maybe you can figure out where I went wrong.
Would you mind sharing how you accomplished the crossflash (SN740 → SN770).
I am stuck at activating the downloaded firmware in nvme-cli. I am getting the same error as you originally did:
NVMe status: Firmware Activation Prohibited: The image specified is being prohibited from activation by the controller for vendor specific reasons(0x4113)
There was no special sauce, it “just worked” once I tried the 731120WD firmware. Unfortunately I don’t know the exact command I used, but I’m pretty sure it was just the usual suggested commands …
…with maybe a different slot (-s 2) and/or action (-a 3)
My best guess is that the “Vendor specific reasons” means that the drive thinks the firmware isn’t suitable for some reason (like doesn’t pass checksum, or is for a different drive). Make sure the firmware downloaded correctly, and that you have the firmware you think you do.
I am starting to think that “vendor specific reasons” applies to only special cases, depending on version of firmware present on the device.
In my case, the OEM firmware of the Dell branded SN740 250 GB (P/N: 0098F8) is 70103012 (7010.3012). Was yours btw, 7391.xxxx?
At least for Dell OEM, firmware versions seem to consist of two numbers combined. The first (e.g. 7010) looks like ‘firmware series’ while the second (e.g. 3012) appears to be the actual ‘firmware build’.
So it might be that not all fw upgrade paths are available, because of potential hardware/firmware mismatch. By the way, do you know if nvme-cli checks for fw dependencies prior to flashing a target?
I even tried to flash Dell’s own 7391.4108 by running the OEM updater package via WinPE which failed with a ‘CID’ not found error. Next step is to try 7310.4012, also from Dell, which is from the same series as the present fw on my NVMe.
I will report back any success or otherwise.
Thanks again!
Well that was helpful. I think I have figured out what went on.
It appears that both of us experienced the same 0x4113 error in nvme-cli because we indeed attempted to flash our hardware with incompatible firmware.
SN740 is a somewhat generic brand name reserved for a couple of SSD products, all made by WD but meant for different use cases.
Yours is probably retail and that is you could only flash a WD original firmware (even though you used the SN770 file) whereas mine is Dell branded (pulled off an Optiplex computer) and supports only fimware levels distributed by the OEM. I don’t know though where the compatibility check happens. I’d guess it’s the controller which rejects the alien firmware.
Even the product names differ; Dell uses its own DP/N (0098F8) string along with the one provided by WD, all printed on the SSD label.
In the end I succeeded in flashing 7310.4012 from Dell, which solves the sleep-wake related issues.
Hey I followed your adventures with great interest as I shucked a Sandisk SSD from an Extreme 4TB enclosure that no longer worked.
I discovered that the drive inside is a SN850XE … note the E…
and there’s a firmware version 624131EX that prevents normal speeds (capped 250MB/sec) once used in a regular NVME slot.
So I’m trying to crossflash it with the 624361WD.fluf for the SN850X retail, but no matter what I do, it does not apply the firmware, even though it seems to do it…
Yes, I reboot, but firmware isn’t activated on reboot I wish you could force the firmware. And by the way, which is weird, the message appears instantly, not more than 1 sec of loading the firmware, it’s instant… shoudn’t it longer ?
I wish you could force the firmware. And by the way, which is weird, the message appears instantly, not more than 1 sec of loading the firmware, it’s instant… shoudn’t it longer ?