Rock64 and UASP support

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • marcellom wrote:

      OMV works out of the box with it or I have to do something?
      OMV has nothing to do with it, this is solely a question of
      • USB device announcing being UAS capable (some do that aren't in reality, eg. Norelsys USB enclosures)
      • kernel/driver of the host in question
      • host settings (eg. UAS blacklisting -- currently all OMV variants for ARM boards try to blacklist everything from Norelsys, Seagate and WD)
      You can check whether UAS is used or the older Mass Storage protocol is in use by looking at the output from 'lsusb -t'. The result will be either uas or 'usb-storage'.
    • Ok boys, everything seems ok:

      pastebin.com/Zrxa5VxH

      I have this
      1. Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
      2. |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
      and this

      bInterfaceProtocol 98

      I have this ayufan distro
      jessie-openmediavault-rock64-0.6.14-166-armhf.img.xz
      and cant find any blacklist for uas...in /etc/modprobe.d/

      But...sorry for the question ... if everything's ok, does that means that my board is already using uasp?
      Or do I have to do some additional work to get a higher speed than the declared 90 Mb / s?
      Sorry, for me is little hard find right informations....
      Thank you for patience...


      Edit: this is my Inatek adaptor
      inateck.com/it/hard-drive-acce…inateck-ua1004-black.html

      The post was edited 1 time, last by marcellom ().

    • SilverBlade wrote:

      Is this for WD/Seagate Enclosures only, or does this apply to WD/Seagate Hard Drives?
      This applies to all USB devices that share Seagate's or WD's vendor ID (0x0bc2 or 0x1058) and the two broken Norelsys chipsets (here also the product ID is examined)

      As a reference: the ROCK64 OMV images do it this way: github.com/ayufan-rock64/linux…ix_performance.sh#L34-L55 and on all the other Armbian based OMV images it's done this way: github.com/armbian/build/blob/…nit.d/armhwinfo#L351-L374
    • tkaiser wrote:

      This applies to all USB devices that share Seagate's or WD's vendor ID (0x0bc2 or 0x1058) and the two broken Norelsys chipsets (here also the product ID is examined)

      As a reference: the ROCK64 OMV images do it this way: github.com/ayufan-rock64/linux…ix_performance.sh#L34-L55 and on all the other Armbian based OMV images it's done this way: github.com/armbian/build/blob/…nit.d/armhwinfo#L351-L374
      I'm not too sure if Vantec or Mediasonic uses those. They don't exactly share that kind of information before purchase, sadly.
    • SilverBlade wrote:

      I'm not too sure if Vantec or Mediasonic uses those. They don't exactly share that kind of information before purchase, sadly.
      That's why I buy chipsets and not brands. All vendors out there use the same USB3 chipsets from ASMedia, JMicron, VIA, Genesys Logic and a few others.

      These vendors then get usually an own firmware from their chip vendor and at least with some chipsets then it's possible to fix some stuff (most recent example is JMicron JMS578 where we now even have a Linux tool that runs on ARM to update/backup firmware). Even Seagate and WD use one of those chipsets from these few vendors (AFAIK they use both ASMedia chips) but their firmwares use some sort of 'branding' and a different vendor and product ID so from now on quirks that should be applied to eg. ASM1153 can not be applied any more since they changed the IDs that are normally used to identify a specific device (can be checked with 'lsusb' command in Linux).

      BTW: This whole UAS blacklisting thing is nothing one should be concernced about with HDDs since the performance degradation is only minimal with HDDs comparing UAS and the older Mass Storage mode. With SSDs it makes a huge difference though but AFAIK neither Seagate nor WD sell SSDs in USB enclosures (though might change now that WD bought SanDisk)
    • SilverBlade wrote:

      How do you check the chipset of an enclosure before purchasing?
      By searching for the name of the chipset? Eg. JMS578: amazon.com/s/ref=nb_sb_noss?ur…aps&field-keywords=jms578

      After purchase I attach it, then call lsusb and if it's not 0x152d:0x0578 (vendor ID followed by product ID) the thing will be returned. Please note that by using this technique on Aliexpress I was able to buy two crappy Norelsys enclosures since JMS578 was mentioned in the product title and only somewhere in the text was written that it's Norelsys NS1068X in reality (which claims to be UASP capable but isn't so needs blacklisting to get disks behind working properly)
    • I have an Anker USB 3.0 to SATA adapter using the dreaded Asmedia chipset. I'm sure that it's a 1053e which should do UAS okay, but because of the v174cp55aa modules thing, it only loads the usb-storage driver. I tried adjusting the entry in modules.alias (I know) and then commenting the entry, but it always ends up with usb-storage as the driver after rebooting. Is there some way for a mere mortal to get this working with uas?

      I'm using an SSD and this seriously limits the transfer rate. I know that even with gigabit Ethernet, it's limited at the network interface, but I'm a bit OCD and can't sleep well knowing that my drive is only transferring data at 250MB/second instead of 500. ;)