rtl9210: a firmware archive for Realtek USB to NVMe bridges

What the project collects and where the blobs come from

The repository is described as firmware and tools for the RTL9210A and RTL9210B USB to NVMe and SATA bridge controller, and the description says plainly that they are provided by station-drivers.com, Realtek, and others. The README asks people not to hesitate to support station-drivers.com, describing it as a great source for drivers and firmware.

That origin explains the shape of the project. These bridge chips ship in inexpensive USB storage enclosures, and the firmware that comes on the device is often old, sometimes badly matched to the silicon revision, and occasionally the reason a drive falls off the bus mid-transfer. Because the firmware is distributed as opaque blobs by the vendor rather than as source, the practical problem for an owner is finding a working blob for their specific chip, and this repository is the place where those blobs are collected and indexed.

The top level of the repository matches that purpose. There is a firmware/ folder holding the archives, a tools/ directory, a configure/ directory, a dump/ directory and an image/ directory. The distinction between dump and image is the one worth understanding: one is a read-out of what a device currently contains, the other is a file to write onto a device. A dump is what you take before touching anything, and the presence of both directories is a strong signal that the project expects you to capture the current state first.

The primary language of the repository is recorded as Python, which is consistent with the tooling being scripts rather than a firmware build, since the firmware itself is a closed binary.

The licence is not identified, and the repository has no GitHub releases, so the firmware blobs are tracked through the git history of the firmware folder rather than through a release stream.

The warning about v1.32.87 and the RTL9210B

The Warning section is the most important text in the repository, and it is not a disclaimer about warranty. It is a specific, actionable data safety statement.

The README says it cannot be emphasized strongly enough that a device running firmware version v1.32.87 in conjunction with an RTL9210B could put your data at risk, due to instabilities at the USB protocol level, and that an update to at least v1.33.44 is therefore considered absolutely necessary.

Three things follow from that wording. The failure mode is at the USB protocol level, which means it is a transport problem rather than a disk problem, so the symptoms are likely to look like the enclosure disconnecting, not like a failing drive. It is the combination of that specific firmware and that specific chip revision that is called out, which is why the version table tracks chip variants rather than just version numbers. And the recommended target is a minimum, not a suggestion, which means a version older than v1.33.44 on an RTL9210B is not a safe configuration.

The general risk statement sits alongside it. All procedures described in the Git repository are at your own risk, and in case of software issues you can find some solutions in the Unbrick section.

That pairing is the honest framing for the whole project. Flashing firmware on a USB storage bridge is not a low-risk operation, the project says so, and the existence of the Unbrick section is the concession that things go wrong. A repository that included a warning about data risk and a recovery procedure is doing more for the reader than one that shipped blobs with no commentary at all.

The version table, and what the question marks cost you

The firmware table is the centre of the project, and it is a compatibility matrix rather than a list. Each row is a firmware version, and each column is a chip variant: RTL9201(A), RTL9210(A), RTL9210B, RTL9220A, RTL9210C(N) and RTL9220VA. The cells carry a check mark, a cross, or a question mark, and the last column links to the download when one exists.

The check marks are where the information is. Version 1.29.12.011122 is marked for the RTL9201(A) and for the RTL9210B. Version 1.30.21.070622 is marked for both the RTL9210(A) and the RTL9210B, which is one of the few universal blobs in the table. From 1.30.17 onwards the RTL9210B is the chip with a definite mark in almost every row, with 1.30.21.070622 the exception that also covers the RTL9210(A).

The question marks are the practical problem. For most versions the RTL9210C(N) and RTL9220VA columns are unknown, and for many versions the RTL9201(A) and RTL9220A columns are unknown too. There are also rows with no download at all, marked as not found yet, such as 1.23.5 and 1.24.2, and one row, 1.33.5.100623, where the Links column is a dash rather than a link.

Two details show the archive is assembled from what could be found rather than from a complete catalogue. One version is listed twice, 1.31.17.102022 appearing as 1.31.17.102022 and again as 1.31.17.102022 (2), with separate download links, and 1.32.49.140423 appears both plainly and with an Lcd suffix, which suggests different builds for different packaging.

If your device is an RTL9210C or an RTL9220VA, this table will not help you much, and that is worth knowing before you start.

Flashing, configuration and the unbrick path

The README table of contents lists the sections a user needs in order: How to Flash the Firmware, Configuration, Create your own configuration, Unbrick, Firmware changelog, Contribute and Sources.

The order matters, because the configuration step comes before the flash step and there is a separate section for building your own configuration. That is a detail most firmware collections would skip, and its presence suggests the flash procedure needs parameters: which chip revision to target, which blob to write, and how the device is addressed on the bus.

The dump/ directory is the tool for the precaution I mentioned earlier. Reading the current firmware off a device before writing to it gives you two things. It tells you which revision and version the unit is actually running, which is often not what the packaging claims, and it gives you a copy to restore if the new blob does not enumerate. The image/ directory holds what gets written.

The Unbrick section is the acknowledgement that USB bridges can stop enumerating after a bad flash, and because the chip is behind the enclosure, a bricked device is a soldering-level problem if you have no recovery path. The project's own framing is that you should read that section before you need it.

The Firmware changelog section is how you tell which blob fixes what, and the Sources section is where you find the upstream providers named at the top, which is the honest way to check whether a blob is the vendor's own or someone's rebuild.

Where this repository is the wrong answer

The first case is a different bridge chip. The topics list the scope, and it is narrow: converter, dump, enclosure, firmware, flash, microcode, nvme, pcie, realtek, realtek-firmware, realtek-rtl9210, rtl9201, rtl9210, rtl9210-firmware, rtl9210b, sata, ssd and usb. If your enclosure uses an ASM2362, a JMicron or an Innostor bridge, none of this applies and you need the firmware for your chip instead.

The second case is the RTL9210C and RTL9220VA owners, whose columns are mostly question marks. The project is centred on the RTL9210B, with a smaller body of work for the RTL9210(A) and the RTL9201(A).

The third case is a device that does not need firmware at all. A unit that enumerates reliably, shows the full capacity in your system, and never drops off the bus does not need a firmware change, and flashing a working device to a newer version is how people create problems they did not have. The data risk warning in the README is about a specific bad version, not a general invitation to update.

The alternative worth comparing is simply the vendor's own update path, since these enclosures often ship with a Windows or macOS utility that updates the bridge firmware, and the blobs in this repository come from the same vendors in the first place. The difference in approach is that a vendor utility knows the chip revision of the unit it shipped with and refuses to write an incompatible blob, while a downloaded archive needs you to establish the revision yourself from the table. That verification step, identifying the exact chip in your enclosure before you write anything, is the entire value this repository adds, and it is also the step people skip.

Editorial conclusion

rtl9210 is worth bookmarking if you own a USB to NVMe enclosure built on a Realtek RTL9210 bridge and your unit ships with firmware older than the one the project flags as risky, since the archive is the only place these blobs are collected per chip revision and version, and the project is clearly still being updated, with the last push on 2026-10-20. It is the wrong tool if your enclosure uses a different bridge chip entirely, if you need a fix for the RTL9210C or RTL9220 variants, where the table is mostly question marks, and if you are unwilling to accept the project's own statement that all procedures are at your own risk. Before flashing anything, read the Warning section, check which chip revision your device actually is, and make sure you have a recovery path, because the Unbrick section exists precisely because flashing goes wrong.

Frequently asked questions

Official sources

1. bensuperpc/rtl9210 on GitHub
2. Issues
3. README