If you’ve been following my microSD Card Survey, you might have noticed that I publish manufacturer IDs for (almost) all of the cards that I’ve tested (save a few where they came DOA or where I tested them before I thought to dump the registers off the card).
I know that there are other resources out there that have compiled lists of SD card manufacturer IDs, but I thought I’d publish my own based on what I’ve seen during the course of my testing. So without further ado:
| Manufacturer ID | OEM ID(s) | Associated Brand Names |
|---|---|---|
00 | 0000 | Auotkn, “Lenovo” (knockoff), QEEDNS, QWQ, SanDian, “Sony” (knockoff), “Xiaomi” (knockoff) — pretty much any fake flash vendor who wants to cover their tracks. |
00 | 3000 | Auotkn |
00 | 3432 (ASCII: 42) | Somnambulist, Gigastone, “Sony” (knockoff) |
02 | 544d (ASCII: TM) | Kioxia (formerly Toshiba) |
03 | 5344 (ASCII: SD) | SanDisk, WD |
05 | 000c | “Lenovo” (knockoff) |
09 | 4150 (ASCII: AP) | ATP |
1b | 534d (ASCII: SM) | Samsung |
1d | 4144 (ASCII: AD) | ADATA |
271 | 5048 (ASCII: PH) | Delkin Devices, HP, Integral, Kingston, Lexar2, onn., PNY |
28 | 4245 (ASCII: BE) | Lexar2 |
45 | 2d42 (ASCII: -B) | TEAMGROUP |
56 | 5344 (ASCII: SD) | Auotkn, QEEDNS |
6f | 0303 | Hiksemi, Kodak, Lenovo, Microdrive, Netac, XrayDisk |
74 | 4a60 (ASCII: J`) | Gigastone, Transcend |
89 | 0303 | Netac |
9f | 5449 (ASCII: TI) | Amzwn, Kingston, Kodak, Micro Center, Silicon Power |
ad | 4c53 (ASCII: LS) | Amazon Basics, Chuxia, Lexar3, OV, Raspberry Pi4 |
df | 2306 | Lenovo |
fe | 3432 (ASCII: 42) | ALUNX, Auotkn, Bekit, Cloudisk, HP, Reletech |
1Multiple sources attribute this manufacturer ID to Phison. While I don’t disagree, I just haven’t come across any Phison-branded cards yet.
2The cards tested here dated to before Lexar’s sale to Longsys.
3The cards tested here dated to after Lexar’s sale to Longsys.
4The announcement on Raspberry Pi’s website specifically mentions that they worked with Longsys to develop these cards — so I think that pretty much confirms that this manufacturer ID belongs to Longsys.
https://www.amazon.it/KOOTION-MicroSDHC-Velocità-Telefono-Videocamera/dp/B07WLY8WHP/ref=sr_1_3?th=1
UHS-I speed SDR104 SDHC KOOTION
hwrev 0x1, oemid 0x4254 (BT), cid c44254534441424310aa0007340196e1, dsr 0x404, manfid 0x0000c4 (?), scr 02b5800300000000, type SD, csd 400e005a5b590000e8f77f800a404027, name SDABC, serial 0xaa000734, date 06/2025, fwrev 0x0, ocr 0x00300000, rca 0xb36b, ssr 0000000008000000040290000f09190a001e00000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Thanks for this! Ok, so here’s what this tells me:
c4, OEM ID4254(ASCII:BT) — haven’t seen this one before!SDABC— I have seen before, several times — with Kodak, Lenovo, Microdrive, Netac, and XrayDisk cards. At first I thought it was a joke, but it’s come up often enough now that I’m pretty sure they just made something up because there had to be a value there. In fact, all the other cards with product nameSDABChave STMicroelectronics’s manufacturer ID on them — so I’d be willing to hedge a bet that they at least had a hand this one as well.One question — what card reader were you using that you were able to pull this information?
Hi Matt,
I used this for the small SD card on SPI bus: http://81.56.4.18:21510/share/IOToL_-rRjDW1GJt/sdreader.avif .
It is a very economical product but has the limitation of not taking advantage of the 50 and 104 MB/s speeds offered by SDIO. The cheapest way to make it is to buy the components here: https://arace.tech/products/milk-v-duo and https://arace.tech/products/usb-to-ttl-cable so you can use it without a monitor via USB.
I would like to suggest you three best purchases with which you can test the UHS-I in SDR104 starting from the cheapest one https://arace.tech/products/radxa-rock-3c-blue-edition to the best supported https://www.raspberrypi.com/products/raspberry-pi-5/ or https://www.raspberrypi.com/products/raspberry-pi-500/ .
You will find the Linux images here for Milk-V: https://github.com/milkv-duo/duo-buildroot-sdk/releases/ (very poor hardware and software); here for the Raxda Rock 3 model C: https://github.com/armbian/community/releases/download/25.11.0-trunk.21/Armbian_community_25.11.0-trunk.21_Rock-3c_bookworm_current_6.12.41_minimal.img.xz (bad software support) and here for all Raspberry Pi: https://www.raspberrypi.com/software/operating-systems/ (the most expensive).
You won’t need any external USB adapter and in the case of Raspberry Pi you can interact even outside your network.
I saw your wishlist and I’m convinced that it’s a mistake to buy mini PCs with USB adapters. In the models I indicated, you will find all the information in the Linux filesystem and you’ll just need a script to extract them, like this one:
#!/bin/bash
cd /sys/class/mmc_host/mmc?/mmc?:*
echo “MID OID PNM PRV PSN MDT”
echo “manfid oemid name hwrev fwrev serial date”
echo “$(cat manfid) $(cat oemid) $(cat name) $(cat hwrev) $(cat fwrev) $(cat serial) $(cat date)”
Thanks Christian!
I want to address one thing you said:
You may be right, but only because it looks like Trigkey upped the price of the particular mini-PC that I was getting. But I want to dig into that a little further.
To start off, I try to run these cards as fast as they’ll go. (Honestly, I don’t see the point in doing any less.) I have 121 cards in testing right now, but I don’t have/need/want 121 PCs, Raspberry Pis, or other SBCs to test them on — not to mention the power or network infrastructure I’d need to run all of them — so I try to set up each machine with 8 cards each. Why 8? I could (and currently do) run more than 8 cards at a time on some of my machines, but the problem is that if you have more than about 7 cards reading at 90MB/sec (the upper end of sequential read speeds that I tend to get from UHS-I-enabled cards), you’ve saturated the bandwidth of a single USB 3.0 bus. However, at any given time, not all cards are being read from — some cards are being read from, some cards are being written to, and in general, write speeds are much slower than read speeds — so I slipped in extra card to take up some of the bandwidth that would otherwise go to waste.
Now…running 8 cards at full speed usually requires a little bit of CPU power. I have a few cheaper SBCs that support USB 3.0, and I’ve tried using them before — but they just didn’t have the CPU power to be able to run 8 cards at the same time. The one I’m still using (an Orange Pi 3) only has one card reader hooked up to it, and it can’t even run that one at full speed. I need something more beefy, like a Raspberry Pi 5 (or, in my case, an Orange Pi 5).
So let’s consider the Raspberry Pi 5. There’s four versions — a 2GB version, a 4GB version, an 8GB version, and a 16GB version. How much memory do I need? Well…right now, the biggest memory suck in my program is the sector map — it needs about 1 MB of RAM for every 2GB of space on the SD card — or about 128MB of RAM for a 256GB microSD card — and it needs that for the entire time the endurance test is running. (It also needs another 8MB of RAM per 3GB of SD card space for writing saving states — but that memory gets allocated at the time the save state is being written and freed as soon as it’s done, so that particular requirement is transient.) If I’m testing 8 256GB cards at a time, then I’d need at least 2GB of RAM. That doesn’t include the memory that the program needs for other things, as well as the memory needed by Linux and the services that run on it. To have a good safety margin, I’d want the rig to have at least 8GB of RAM. If I just wanted to get a barebones setup, I can get the 8GB version of the Raspberry Pi 5 and a power supply for about for $93 USD.
I also need a good amount of disk space. When a card starts to go bad and bit flips start happening, my program logs the expected data and the data that it actually read back — and that takes up a lot of space, especially for bigger cards. I have log files that are tens and even hundreds of gigabytes in size, even after I’ve compressed them. Ideally I’d want at least 1TB of storage space on each of my testing rigs…but I’ve found that I can get away with 500GB as well. The Raspberry Pi 5 doesn’t have any NVMe or mSATA slots on it, so I’d have to get a microSD card for it. Just doing a cursory look on Amazon, it looks like 512GB microSD cards can be had for about $35 — so now I’m spending $128 total.
Alternatively, I can get a mini-PC for $129 that has twice as much RAM and a proper SSD that will perform far better than the microSD card would have.
So no — I don’t think it’s a mistake to buy mini-PCs for the type of work I’m doing.
Thank you for your comment!
I found your arguments excellent. I have a Raspberry Pi 5 with an M2 SSD and you really wouldn’t be able to test more than three high-speed cards at the same time, using the two full-speed USB 3 ports and a third on SDIO.
Unfortunately I haven’t been able to verify this because I need to resolve the warnings I got when trying to compile your code.
Even the idea of changing the way you test the SD would introduce new problems. Honestly, I wasn’t thinking of a way to test the speed and reliability of the cards, but just the easiest way to get all the related information, from operating voltages to the optimal size of the formatted clusters, which are extractable from the Linux filesystem even with a Raspberry Pi Zero 2 W, while the other machines are doing something else. Your followers need to be able to easily share and verify your experiments, so they can build interest in your work, so it wouldn’t be a bad idea to fulfill the request you received on GitHub to also have the binaries.