Samsung PM1735 - No drivers, no firmware found anywhere?

[nmasse-itix]

Hello !

I recently bought a couple of PM1735 drives on eBay.

I have been able to update two of them to the latest firmware I could find. And it enabled a couple of new features (32 namespaces, SR-IOV, etc.).

$ sudo nvme fw-log /dev/nvme0 
Firmware Log for device:nvme0 
afi  : 0x22 
frs1 : 0x51354241394b5045 (EPK9AB5Q) 
frs2 : 0x51354247394b5045 (EPK9GB5Q)

However, the last drive I bought refuses the firmware :

$ sudo nvme fw-commit /dev/nvme0 -s 0 -a 1
NVMe status: Invalid Firmware Image: The firmware image specified for activation is invalid and not loaded by the controller(0x107)
Multiple Update Detected (MUD) Value: 0

$ sudo nvme fw-log /dev/nvme0
Firmware Log for device:nvme0
afi  : 0x11
frs1 : 0x51334130394b5045 (EPK90A3Q)

$ sudo nvme list
Node                  Generic               SN                   Model                                    Namespace Usage                      Format           FW Rev 
--------------------- --------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1          /dev/ng0n1            S5XENE0N808577       SAMSUNG MZPLJ6T4HALA-00AMV               1           6.40  TB /   6.40  TB      4 KiB +  8 B   EPK90A3Q

Does anyone knows how to find the name of the OEM selling this drive ?

Note: the format 4kiB + 8B looks strange to me. Does it ring a bell to you ?

 

[mr44er]

Does it ring a bell to you ?

Yes. If you don't have that 'special' system where they're from, you don't want that. That is the same 8byte for CRC as in 520b sector size on SAS disks.

Hardware — OpenZFS documentation

openzfs.github.io

You either want 512, 4096 (4k) or 8192 (8k). Likely the highest sector size gives the best performance, if this disk supports that. Regardless of the firmware you must reformat anyway, you can't do wrong with choosing 4k.

I'm not experienced with Samsungs, there is a small chance that the other firmware works after it has been formatted to 4k.
00007 should be Lenovo, 00AMV leaves me clueless.

 

[nmasse-itix]

I spent time on ebay searching for "samsung 00AMV" and I finally found a Samsung drive with that suffix AND a sticker on the back with a product number.

That product number seems to match a Dell product.

So, 00AMV might be Dell.

I reformatted the drive to 4K. I will try to update the firmware again tomorrow.

 

[nmasse-itix]

After some googling / ebaying, here is the information I could gather about OEM
- 00AD3 => Dell-EMC
- 00AH3 => HPE
- 000H8 => HPE
- 000H3 => HPE
- 00AMV => ?
- 00AFB => ?
- 000MV => Dell
- 000V5 => Lenovo
- 000D3 => Dell-EMC

I found the firmware for the Lenovo version and HPE version.
- Online NVMe SSD Flash Component for Linux (x64) - MZPLJ1T6HBJR-000H3, MZPLJ3T2HBJR-000H3 and MZPLJ6T4HALA-000H3 Drives
- ThinkSystem PM1735 Mainstream NVMe PCIe 4.0 x8 Flash Adapters

For HPE, it was a matter of downloading and unpacking the RPM (download link above).

$ rpm2cpio /tmp/firmware-hdd-6628fce235-EPK76H3Q-2.1.x86_64.rpm | cpio -id
$ ls -lh usr/lib/x86_64-linux-gnu/firmware-hdd-6628fce235-EPK76H3Q-2.1/
total 19M
-rw-r--r--. 1 root root  69K Jun 29 08:17 CP052529.xml
-rw-r--r--. 1 root root 5.8M Jun 29 08:17 EPK76H3Q.bin
lrwxrwxrwx. 1 root root    5 Jun 29 08:17 hpsetup -> setup
-rw-r--r--. 1 root root  13M Jun 29 08:17 libsetup.so
-rw-r--r--. 1 root root 2.2K Jun 29 08:17 payload.json
-rwxr-xr-x. 1 root root 6.8K Jun 29 08:17 setup

$ sudo nvme fw-download /dev/nvme0 --fw=usr/lib/x86_64-linux-gnu/firmware-hdd-6628fce235-EPK76H3Q-2.1/EPK76H3Q.bin  
Firmware download success

$ sudo nvme fw-commit /dev/nvme0 -s 0 -a 1
NVMe status: Firmware Activation Prohibited: The image specified is being prohibited from activation by the controller for vendor specific reasons(0x113)
Multiple Update Detected (MUD) Value: 0

For Lenovo, I had to use OneCLI to download the update for a compatible server (7z71)

$ curl -sSfLo /tmp/lnvgy_utl_lxce_onecli02c-4.1.0_linux_x86-64.tgz https://download.lenovo.com/servers/mig/2023/05/19/57616/lnvgy_utl_lxce_onecli02c-4.1.0_linux_x86-64.tgz
$ mkdir $HOME/local/packages/lenovo-onecli
$ tar -zxf /tmp/lnvgy_utl_lxce_onecli02c-4.1.0_linux_x86-64.tgz -C $HOME/local/packages/lenovo-onecli
$ cd $HOME/local/packages/lenovo-onecli
$ ./onecli update acquire --mt 7z71 --ostype none --scope latest --dir ~/tmp/lenovo-pm1735
$ ./onecli update acquire --mt 7z71 --ostype rhel7 --scope latest --dir ~/tmp/lenovo-pm1735
$ ./onecli update acquire --mt 7z71 --ostype rhel8 --scope latest --dir ~/tmp/lenovo-pm1735

$ grep -ri pm1735 ~/tmp/lenovo-pm1735
lnvgy_fw_drives_all-1.50.16-0_linux_x86-64.chg:       pm1733/pm1735 -->CQ35 \CQ37\CT 32\CT31  --> CQ35.00.00 \CQ37.00.00\CT 32.00.00\CT31 .00.00

$ grep -ri B96M .
grep: lnvgy_fw_drives_all-1.50.16-0_linux_x86-64.bin: binary file matches
grep: lnvgy_fw_drives_all-1.40.05-0_linux_x86-64.bin: binary file matches
grep: qlgc-lnvgy_fw_fc_qla-2690.2700-1.94.06.c_linux_x86-64.bin: binary file matches
grep: qlgc-lnvgy_fw_fc_qla-2770.2772-4.04.06.c_linux_x86-64.bin: binary file matches

$ file lnvgy_fw_drives_all-1.50.16-0_linux_x86-64.bin
lnvgy_fw_drives_all-1.50.16-0_linux_x86-64.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.4, BuildID[sha1]=91d276be52a5eddd6826fe09f6fa45eaf14ba9da, with debug_info, not stripped

$ less lnvgy_fw_drives_all-1.50.16-0_linux_x86-64.txt

$ chmod 755 ~/tmp/lenovo-pm1735/lnvgy_fw_drives_all-1.50.16-0_linux_x86-64.bin
$ mkdir /root/lenovo-pm1735
$ ~/tmp/lenovo-pm1735/lnvgy_fw_drives_all-1.50.16-0_linux_x86-64.bin -x /root/lenovo-pm1735
$ ls -lhS /root/lenovo-pm1735/files/ | head -n 15

-rwxr-xr-x. 1 root root  6.5M Jun 29 08:32 lngnx7g0.bin
-rwxr-xr-x. 1 root root  6.4M Jun 29 08:32 p600.bin
-rwxr-xr-x. 1 root root  6.4M Jun 29 08:32 pqgnk9z0.bin
-rwxr-xr-x. 1 root root  6.3M Jun 29 08:32 k6z0.bin
-rwxr-xr-x. 1 root root  6.2M Jun 29 08:32 ct31.bin
-rwxr-xr-x. 1 root root  6.2M Jun 29 08:32 cq35.bin
-rwxr-xr-x. 1 root root  6.0M Jun 29 08:32 ct32.bin
-rwxr-xr-x. 1 root root  5.9M Jun 29 08:32 ctb2.bin
-rwxr-xr-x. 1 root root  5.9M Jun 29 08:32 cqb6.bin
-rwxr-xr-x. 1 root root  5.8M Jun 29 08:32 cq37.bin
-rwxr-xr-x. 1 root root  4.7M Jun 29 08:32 mq31.bin
-rwxr-xr-x. 1 root root  4.4M Jun 29 08:32 mp33.bin
-rwxr-xr-x. 1 root root  4.1M Jun 29 08:32 pcgnk9y5.bin
-rwxr-xr-x. 1 root root  4.0M Jun 29 08:32 cc44.bin

$ ls -l /tmp/General_PM1733_EVT0_EPK9GB5Q.bin
-rw-r--r--. 1 nicolas nicolas   6081536 Nov 16  2022 General_PM1733_EVT0_EPK9GB5Q.bin

$ cd /root/lenovo-pm1735
$ ls -l files/ct32.bin files/ctb2.bin files/cqb6.bin files/cq37.bin
-rwxr-xr-x. 1 root root 6063104 Jun 29 08:32 files/cq37.bin
-rwxr-xr-x. 1 root root 6180864 Jun 29 08:32 files/cqb6.bin
-rwxr-xr-x. 1 root root 6194176 Jun 29 08:32 files/ct32.bin
-rwxr-xr-x. 1 root root 6182912 Jun 29 08:32 files/ctb2.bin

$ grep -ri MZPLJ6T4HALA .
grep: ./flashdrv.bin: binary file matches

$ ls -lh flashdrv.bin
-rwxr-xr-x. 1 root root 151K Jun 29 08:32 flashdrv.bin

$ strings flashdrv.bin | grep MZPLJ6T4HALA
MZPLJ6T4HALA-000V5

$ strings flashdrv.bin | grep -B 1 -A 2 MZPLJ6T4HALA
SSS7A43109
MZPLJ6T4HALA-000V5
CQ37
cq37.bin

$ nvme fw-download /dev/nvme0 --fw=files/cq37.bin
Firmware download success

$ sudo nvme fw-commit /dev/nvme0 -s 0 -a 1
NVMe status: Firmware Activation Prohibited: The image specified is being prohibited from activation by the controller for vendor specific reasons(0x113)
Multiple Update Detected (MUD) Value: 0

But the cross-flash failed with both HPE and Lenovo firmware :

Firmware Activation Prohibited: The image specified is being prohibited from activation by the controller for vendor specific reasons(0x113)

I think I will leave the firmware of this card "as-is" for now.
I'm leaving the results of my investigations for anyone that stumble on this later...

 

[mr44er]

After some googling / ebaying, here is the information I could gather about OEM
- 00AD3 => Dell-EMC
- 00AH3 => HPE
- 000H8 => HPE
- 000H3 => HPE
- 00AMV => ?
- 00AFB => ?
- 000MV => Dell
- 000V5 => Lenovo
- 000D3 => Dell-EMC

Yes, that is good research! I don't like this attempt to encrypt/hide the vendor behind this...

Some cross-reference: https://forums.servethehome.com/ind...r-hgst-helium-drives.38730/page-2#post-382382

Maybe it would be useful to collect more ID Codes and have them sticky?

 

[buju]

I am not exactly the worlds leading expert for SSD benchmarks on Windows, but I think some variance between different benchmark is to be expected.