Update firmware WD Black SN770 firmware on Arch Linux

Update firwmware WD Black SN770 firmware on Arch Linux.md

Update firmware WD Black SN770 firmware on Arch Linux

Been having problems with my new SN770 drive, and decided to check if I can firmware update it on Linux. WD only provides a Windows tool, Western Digital Dashboard to download and install firmwares, but, it's possible to find the firmware and install it using Linux tooling as well.

1. Check that nvme-cli is installed:

❱ sudo pacman -S nvme-cli

2. Find the current firmware version

Run nvme to check which firmware version is installed:

❱ sudo nvme id-ctrl /dev/nvme0 | grep "fr "
fr        : 731100WD

In my case it tells that firmware is 731100WD.

3. Find and download the firmware for your drive

Open the URL that the WD Dashboard Downloads uses, and find your drive in the list: https://wddashboarddownloads.wdc.com/wdDashboard/config/devices/lista_devices.xml

My drive was here:

<lista_device model="WD_BLACK SN770 1TB">
  <url>wdDashboard/firmware/WD_BLACK_SN770_1TB/731120WD/device_properties.xml</url>
</lista_device>

From there look at the device_properties.xml, https://wddashboarddownloads.wdc.com/wdDashboard/firmware/WD_BLACK_SN770_1TB/731120WD/device_properties.xml:

<ffu version="1.0">
<model>WD_BLACK SN770 1TB</model>
<fwmode>mode3</fwmode>
<fwversion>731120WD</fwversion>
<fwfile>731120WD.fluf</fwfile>
<dependency model="WD_BLACK SN770 1TB">731030WD</dependency>
<dependency model="WD_BLACK SN770 1TB">731100WD</dependency>
</ffu>

Now we can download the fluf file: https://wddashboarddownloads.wdc.com/wdDashboard/firmware/WD_BLACK_SN770_1TB/731120WD/731120WD.fluf

The fluf file is the firmware format for the WD drive. It contains checksums and drive identifiers, so the drive controller should fail if you try to install a wrong firmware, but, better double-check that you have the correct one :-)

4. Apply the firmware

Use nvme to download firmware and commit it. Both commands should be successful.

❱ sudo nvme fw-download /dev/nvme0 -f ./731120WD.fluf
❱ sudo nvme fw-commit -s 2 -a 3 /dev/nvme0

Finally reboot, and step 2 again to check that the firmware is running on the correct version.

This worked on Ubuntu 22.04 as well.

I tried this with a SN850 but get the following error:

NVMe status: Invalid Firmware Slot: The firmware slot indicated is invalid or read only(0x4106)
Multiple Update Detected (MUD) Value: 34144265
Detected an overlapping firmware/boot partition image update command sequence due to processing a command from a Management Endpoint

nvme fw-log /dev/nvme1

gives

Firmware Log for device:nvme1
afi : 0x1
frs1 : 0x4457303031313136 (611100WD)

Thank you so much! The -s 2 -a 3 arguments were critical for me to successfully update the firmware for my SN770. Without those flags everything seemed to be working but the firmware revision just wouldn't change.

Thank you so much! The -s 2 -a 3 arguments were critical for me to successfully update the firmware for my SN770. Without those flags everything seemed to be working but the firmware revision just wouldn't change.

Same experience for me, with the 2TB variant.

I think, in the output of nvme fw-log, afi is the active firmware slot, and frsN are the populated slots (but the newly nvme fw-downloaded one was not visible for me).

Came here from this issue, albeit on a self-built system with an AMD Ryzen 7 5700X on a Gigabyte X570 AORUS ELITE mainboard.

I wrote a small bash script doing the above - I did update both my SN770M and SN850X via it - if anyone wants to try it out and give feedback (I tested it only on CachyOS running on my Framework16 laptop) -> https://github.com/magicdude4eva/wd-nvme-fw-updater/tree/main

Just a heads up that it seems there is now the 731150WD version for SN770 1TB.

Btw, I asked Gemini to generate a changelog based on the data it had access to and it generated this (be aware that it might be incorrect due to GenAI):

---

WD_BLACK SN770 Firmware Changelog

731030WD (Launch Base)

• Architecture: Initial DRAM-less controller firmware utilizing Host Memory Buffer (HMB).
• Flaw: Controller contains a latent memory management flaw crashing the SSD if the host OS allocates more than 64MB of HMB space.

731100WD

• Changes: Minor thermal curve adjustments.
• Flaws: Fails to sustain deep I/O queues without reporting AER logs, causing the controller to drop offline during heavy asynchronous bursts. Mismanages Linux APST (Autonomous Power State Transitions), freezing during suspend/resume.

731120WD

• Fixes: Partially corrects the HMB allocation routine to prevent silent PCIe transport failures (which cascaded into Data Fabric Sync Floods on modern AMD platforms).
• Flaws: Still fails under full 200MB HMB allocation.

731150WD (Current - Your Version)

• Critical Fix (HMB Overallocation): Completely overhauls the FTL metadata caching logic against aggressive host HMB scaling. The drive now properly handles the full 200MB allocation via PCIe without faulting.
• Linux Stability: Fixes the spontaneous nvme_core APST deep-sleep lockups. Eliminates the need to force nvme.hmb=64 or disable pcie_aspm at the kernel parameter level.

---

This new release also seems to be relevant to the Windows 11 24H2 NVMe incident:

---

The Catalyst: Microsoft refactored the native NVMe driver (stornvme.sys) in Windows 11 24H2 to remove its legacy 64MB Host Memory Buffer (HMB) cap, shifting to dynamically allocate whatever memory footprint the drive requested.

The Hardware Collision: The SN770 hardware registers advertise a 200MB HMB capability. However, firmware 731120WD and older contained a severe memory addressing fault. When stornvme.sys granted the requested 200MB, the controller attempted to cache FTL metadata in bounds beyond 64MB, suffered a segmentation fault, and instantly dropped off the PCIe bus (resulting in a hard lock and INACCESSIBLE_BOOT_DEVICE BSOD).

Mitigation & Resolution: Microsoft pushed an emergency OS mitigation via a hardware ID (HWID) registry clamp, forcing the drive back to 64MB. Firmware 731150WD directly patches the internal memory addressing logic, allowing the controller to safely utilize the full 200MB HMB boundary and run at its native architectural specification.

---

So, whoever runs into this comment should probably update.