Skip to content

Fix: JMicron JMS583 USB-NVMe bridge support#315

Open
flowswitch wants to merge 2 commits intoDrive-Trust-Alliance:masterfrom
flowswitch:master
Open

Fix: JMicron JMS583 USB-NVMe bridge support#315
flowswitch wants to merge 2 commits intoDrive-Trust-Alliance:masterfrom
flowswitch:master

Conversation

@flowswitch
Copy link
Copy Markdown

@flowswitch flowswitch commented Jan 11, 2020

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.

@UtilFunction
Copy link
Copy Markdown

Why has this pull request not been merged? Maybe @flowswitch can provide binaries?

@Blacklands
Copy link
Copy Markdown

Blacklands commented May 11, 2023

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.
There's also a ton more things in the OPAL spec that sedutil still doesn't support at all (like anything regarding users), and no work is being done on that either.

@scottcmarks
Copy link
Copy Markdown
Contributor

I have not checked my bridges to see if I have a JMS583, but I am guessing that the more recent develop code may have avoided the issue mention by @UtilFunction and @Blacklands and originally by @flowswitch simply by virtue of the heuristic of SCSI-first.

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?

@scottcmarks scottcmarks self-assigned this May 3, 2025
@flowswitch
Copy link
Copy Markdown
Author

Confirming, the recent code (commit 136389c) works via JMS583 bridge. My PR is obsolete now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants