Fix: JMicron JMS583 USB-NVMe bridge support#315
Fix: JMicron JMS583 USB-NVMe bridge support#315flowswitch wants to merge 2 commits intoDrive-Trust-Alliance:masterfrom
Conversation
|
Why has this pull request not been merged? Maybe @flowswitch can provide binaries? |
This repo is very dead, unfortunately. I think @r0m30 has been the only maintainer for a long time, and they're almost or entirely inactive. There's so many things that still need to be done, multiple forks that implement various additional functionality (like sleep support, a better hash function, an updated preboot environment) but nothing gets merged back into here or consolidated elsewhere. I lost track of all the different forks and what they add/improve at this point. |
|
I have not checked my bridges to see if I have a JMS583, but I am guessing that the more recent That is, when constructing the lower-level block storage device (which is later vetted to be a TPer or not by Level 0 discovery), the approach is to start out with all the information given to us by the OS, and add to that everything we can get from the actual device. If that device is reported to be SCSI or SAS, we go through all the SCSI VPD information pages that are provided, and ultimately will try SCSI SECURITY PROTOCOL IN/OUT` for discovery 0 and IF SEND/RECEIVE. If those don't work, we try ATA PASSTHROUGH to see if it is a SATA device, where we will try TRUSTED SEND/RECEIVE. This is why I think current code might resolve the problem. Does it? |
|
Confirming, the recent code (commit 136389c) works via JMS583 bridge. My PR is obsolete now. |
The JMS583 firmware supports SCSI SECURITY PROTOCOL IN/OUT commands (relaying them to NVMe side correctly), but it also handles the ATA PASS THROUGH command (in a vendor-specific way, implementing an NVMe pass through), so sedutil gets an empty response to ATA PASS THROUGH (but no command error) and treats the drive as SATA w/o OPAL support without trying the SCSI method.
This patch adds probing the SCSI method in case of empty ATA PASS THROUGH response, so the drive gets detected as SAS at the end and works correctly.