EC-UASP - more information


  • Hello,

    Could you provide more information about this product? https://sabrent.com/collections/enclosures/products/ec-uasp

    - Which chipset does it use? I've bought a DS-4SSD and found out it is in fact not on JMS567+JMB575 (as suggested here: https://sabrent.com/community/xenforum/topic/84363/ds-4ssd-will-not-start-disks-same-disk-stars-fine-in-the-ec-uasp-adapter ), but on JMS561U, which doesn't even support TRIM/DISCARD or hot-swap or even hot-plug, not to mention proper USB support and other weird behaviour. Now I have to double-check what I'm buying, and there is no mention of the chipset anywhere on the product page.

    - How exactly is it "tool free"? There is no picture of it being disassembled.

    - Is it actually called "EC-UASP" as specified under "SKU", or "EC-UM30" as specified under "Package Content"? Does that mean it properly supports UASP, or is that just a model name? Being marketed as SSD-compatible, does it support TRIM/DISCARD?

    - What type is the "USB 3.0 cable" specified under "Package Content"? Is it USB-A to USB-A , as I'm trying to guess by the picture that does not have a cable?

    - What is the difference between this product and "EC-UK30" (which also has "EC-UM30" under "Package Contents")?



  • Oh, it's also JMS561U, isn't it... At least for those who actually bought it.

    https://forum.odroid.com/viewtopic.php?p=304941


  • Reading about Sabrent products on the Internet, seems like I have to also ask questions that I would assume should not have to be asked:

    - What is the maximum supported device capacity?

    - Does it support SMART commands?


  • @mad-jester The EC-UASP can use multiple chipsets such as the JMS578 and ASM1053E. These do support UASP and TRIM. If you have any issues with capacity, as may be the case, a firmware update from technical support will fix it. This model has been updated and should have a chipset with TRIM support, however, a firmware update may be required for proper identification.

    It fits together tool-free with a friction fit, which you can more clearly see in the product's Amazon pictures. The EC-UM30 listings were incorrect and have been fixed. The cable is Type-A to Type-A and I've added this information to the Descriptions and/or Tech Specs. The UK30/UM30 models are slim models in two different colors.


  • Thank you for the answers!

    "This model" - do you mean EC-UASP or DS-4SSD? A firmware update can't bring TRIM support into JMS561U, right? At which capacity should I be worried about the limitation with JMS561U?


  • @mad-jester One issue we're seeing is that the product ID shown in programs like USB Device Tree Viewer seems to be incorrect and it may be properly identified with a firmware update. We began testing an EC-UASP we have in the office and will be seeing if TRIM/UNMAP works on this next week. One user on Reddit had a EC-DFFN that identified as 0x1561 and incorrectly concluded that it meant that it had a JMS561U. The unit would not work with >10TB drives, but after a firmware update it's acting properly.


  • @Sabrent Could it be that my DS-4SSD is also "improperly identified" and is actually supposed to have TRIM?..


  • @mad-jester Yes. You should absolutely get firmware from technical support to see if it helps.


  • (I'm sorry that the discussion has switched off the original topic; I could open another discussion if it's preferable to avoid this. The reason I was looking at other enclosures is to solve a problem this one did not solve.)

    There's no firmware in the "Downloads" section. I've asked support by email to check if there is a new firmware available - that was one week ago, and they are still checking. And in the "quick" question chat, I was "waiting for an available agent" the whole day yesterday, until they were closed for the day. :) Could you please maybe check if a new firmware exists for DS-4SSD? Or find someone who can do it.

    I'm also wondering if there were any units produced with JMS561U (in this case I should be more worried about returning the unit in time), or is this definitely a mis-identified JMS567 (then I should continue waiting for someone to check for a new firmware).


  • @mad-jester I was told no units shipped with the JMS561U. There is new firmware for the EC-UASP but not the DS-4SSD. I replied to you in the other thread that we asked the factory to update the hardware in newer batches to support the features you requested.


  • Then it seems like it is likely not JMS561U, despite identifying as 152d:1561 . And there is no firmware update. But is it possible to fix?..

    Could you share what chipsets did you see in the ones you've opened up? Or what chipsets are they supposed to have. Maybe I can find some information about this problem. Were they the ones supporting TRIM? And UASP, which I'm less concerned about, but also curious.


  • It may in reality be a different chip, but it does report no TRIM support - so even if it actually could support it, those commands won't (can't) be issued by the operating system. So it doesn't matter what's really there as long as it reports 0561 and no TRIM support. It's not "ID reported by some utilities" - it's "ID reported by the device to the OS", so if it's wrong, then the OS will treat it accordingly.

    Maybe this problem could be fixed in firmware, now that people are aware of it?.. AFAIK that's the only way to fix it, and I couldn't find any information to suggest otherwise. If my understanding about this is correct, then it means there are a lot of people with those units who don't know their TRIM is not working, so it would be kind of important to get an fix out for them all. And it would probably be cheaper than designing a new product on a different chipset (and then pretending it's the old product but "slightly" fixed).

    Actually, seems like I could try to spoof the ID to test if that helps (if I find out what chip that actually is), but I don't think it could change the fact that the device reports no TRIM support.


  • @mad-jester I think we have discovered the issue. The one we opened is JMS567. By default this chipset supports UASP with an update but all our models are new enough to have that. However, TRIM seems not to be properly reported. It appears that the ID issue is complicated further because you can flash JMS578 firmware to enable TRIM on this chipset. You can read more about JMicron fun in this Reddit thread. Typically our support team will offer this FW when requested but we plan to move to a chipset that works at stock.


  • So it's almost definitely JMS567 - also this seems a lot like my situation (same weird identification string), so EC-UASP 's on JMS567 might be affected by the same problem (at least a few years back). And this guy has checked the IC visually, which confirms it - and likely did not notice that the device identifies as a completely different chipset.

    This is good news - now that I know the chipset, I can take a look at available firmware updates for it.

    Thank you! Your efforts have changed the situation from "there is no solution" to "now we've found a tricky problem and here's a possible solution".

    A few notes for the record:

    - Contrary to that post, I specifically prefer enclosures with USB-A, because that connector is the only one that can handle the necessary current (and is way more durable). That enclosure is my next choice if I can't get DS-4SSD to work - except if it has the same chipset, it's likely to have the same problems, and there is no way to specifically order a product that you want without "lottery".

    - There are some other issues with JMS567/JMS578 on Linux, particularly with TRIM/UAS, but I'll get to that later (and post my findings), after I fix the firmware. I mean, those issues are not with the device itself, but with the Linux drivers for it (which JMicron does not seem to put any effort into).

    - People are also encountering other issues with some firmware versions, so I'll do my research on that.

    - Finally, the USB connectivity problems that I've observed are most likely not because of the device, but because of my host controller. At least early USB3 implementations seem to have a lot of problems.


  • I've tried to do this, but it did not work.

    The firmware updater has correctly identified my device as "JMS568/567/566" (but not 578!). After I select the firmware file, it shows a warning - "The firmware file seems not match this chip!":

    When I click "Run", it shows "Write Data SCSI16 To HDD FAIL!!":

    I've tried a different update utility, but it just says that this firmware is not applicable to the chip found, and "Start" button is inactive. And I can't use the Odroid linux for some reason: it's a binary file for ARM, so I've installed qemu-static with ARM binfmt support, but the program just says:

    Backup Firmware file name: /tmpfs/backup.bin
    ERR : open device fail
    Get Bridge version FAIL!
    
    ERR : open device fail
    Read Back to Backup Error!!

    I suppose that's because it was written specifically for Odroid, and can not work with different hardware?..

    I could make a backup with the first updater though. And as we can see, it's v01.03.02.04 .

    (Of course, I've connected the device to a USB3 port with the official cable, with one blank HDD in the first slot - but I've also tried with a non-blank SSD in the fourth slot.)


  • I've found only one firmware that did not say "Wrong chip". But it did say "Unable to send SCSI16". So... I guess being a different chip is not a problem, but my USB might be?.. No way, I've got a ThinkPad E330 with a factory Windows 7 installation, which definitely contains all necessary drivers and which I have not touched (I'm keeping it alongside Debian 11 just in case something like this happens).

    Is there anything I should check?.. I have other computers with USB3, but not with Windows, so if there is a Linux amd64 flasher, I can try that. And on Debian, the device is definitely working at USB3 speeds, which means there is no BIOS or hardware problems.

    UPDATE: Could it be that those SCSI commands it's trying to send are supposed to go over UASP, which is "USB attached SCSI", and which is reported unsupported by "JMS561U" firmware? %) Ah, no, it is at least supposed to be supported by the specification. But maybe it's actually broken in this firmware?..


  • @mad-jester The Odroid link was from a user who said he was able to flash and get TRIM working on our JMS567 hardware. There are certainly other/better sources, it was just an example in this case. Was linked in the Reddit thread and maybe you can follow that rabbit hole. UASP is reported as working for our unit under Windows but Linux can be checked. We have been spending some time on figuring this all out for current users who have issues but are updating the unit hardware to prevent future problems.


  • @Sabrent I've found firmwares that should work, and I'll figure out the Linux part later. The problem is, none of the updater programs work for me for some reason. Which program do you use? What could be the reason for "unable to send SCSI commands"?


  • I've managed to get another system, also with certain (and possibly better) working USB3. But the symptoms are the same - "Write Data SCSI16 To HDD FAIL!!".

    Are you actually able to reflash your units this way? What program do you use?


  • @mad-jester For us under Windows we can see UASP is enabled in various programs and the performance is not BOT. Our main concern is TRIM/UNMAP which seems to be unreliably supported. We often write our own updates for the purpose of maintaining an ID that allows our OEM Acronis software to work. We have had issues with the application of firmware updates in some cases which started this investigation for specific users via technical support. I am passing this to the team to see if we can get an updater to work this week.


  • 1 / 2
  • 2
Please login to reply this topic!