How to force USB 3 device to use mass-storage driver using quirks?

MOX hardware MOX HW problems
1

Hello everyone,

I would like to install the NextCloud collaboration platform on my MOX A+F (TOS 4.0.1).

To make use of old 2.5" rotational disks I have around, I bought 4x USB 3.0 Axagon EE25-XA6 enclosures and connected them to the module F. Power adaptor is connected to the module F instead of A.

Unfortunately, this did not worked as expected. MOX is unable to start when the drives are connected (red LED stays ON). The Storage tab in Foris is giving timeouts when the drives are connected after a successful boot.

Further tests revealed, that the disks are working fine when connected to the USB port of module A which is having USB 2.0 port.

Based on this I have checked how is the system handling the Axagon cases when connected to the USB 3.0 port of module F:

lsusb
Bus 003 Device 007:ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge.

lsusb -t
/: Bus03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/4p, 5000M
|_Port 1: Dev 7, If 0, Class=Mass Storage, Driver=uas, 5000M

Googling revealed that some people were facing similar issue in the past and it helped to use mass-storage driver instead of the uas driver.

The OpenWrt forum have a post describing how to force usage of mass-storage driver on a USB 3 port:

I have followed the instructions and added following line in to the /etc/modules.d/usb-storage file:

quirks=174c:1153:u

This did not worked as the Axagon HDD enclosure is still being mounted using the uas driver.

Question: Can somebody advise me how to make the usb-storage quirks work on my MOX?

Alternative solution is to use USB 2.0 cable and connect it to USB 3 port in module F (uas driver is still used though). This gives low transfer speed compared to connecting the HDD enclosure with USB 3 cable to USB 2 port in module A (mass-storage driver is used).

2

I have exactly the same problem. I’m also using ASMedia based Axagon enclosure (only different design) and I spent couple of day trying to figure it out. The funny part of it is that when you plug one of those drives into A, the quirks automatically assigns usb-storage driver to it and I’ve been using it like this for a while. The transfer speed takes a hit but at least I can access my files.

That raises couple of questions:

  • Is the uas driver broken on current version? Are only certain UASP capable chipsets affected?
  • What am I supposed to do when I discover a hurdle like this and it’s a dealbreaker? RMA doesn’t feel like an option to me and “waiting for a new version of kernel” will result in a never ending story.

It kinda puts a damper on my projects when I can’t really trust the MOX. I was planning to get Icybox with 8TB drivers but now I don’t even know if it’s going to work. I tested all of my stuff on more mainstream arch+distro combinations (even UASP running drives at full speed). This makes me wonder if I really should have taken the gamble and use MOX as my “cost effective” all-purpose network device. Sigh.

3

Had you followed this [OpenWrt Wiki] Using storage devices ?

As there are different types of kmod drivers for USB 1,2,3 and and also storage drives. I needed to install opkg install kmod-usb-storage-uas but your situation probably different. You can install via LUCI or with SSH terminal connection. Try fiddle around with different kmod’s

4

So your device is running with the UAS driver just fine? Could you give more information about the manufacturer/model/chipset used? It’s entirely possible that we’re both missing a driver of some sort. I just checked NAS package in Foris (which downloaded most of the kmod usb related stuff anyway), but reading through the forum I got the feeling that one “should skip Foris entirely at any cost”. This may be a lead, but it certainly doesn’t explain most of my other problems I have with MOX.

5

Well FORIS is very very limited what can be setup with it. You can do way more with LUCI even it could be confusing for ordinary users due to lot of parameters. Over SSH terminal you can do practically everything. And don’t expect all needed kernel modules to be installed and loaded by default as simply they are not.

6

I’m not using Foris (apart from installing some of those packages because it’s easier installing them manually). I spend most of the time in LUCI/ssh anyway, please don’t disregard me as a basic user. I’m gonna to have another go at it this evening but it’s really hard to figure out the problem just by looking at dmesg and openwrt documentation because everything seems normal before kernel starts spewing IO errors like crazy. I’m not willing to debug drivers and see what’s wrong with it (as it’s not that simple to do even for the driver dev).

I’m trying to find any information and support I can get here and help others along the way.

I will try to ditch the Foris packages and run minimal configuration and see if that helps but I doubt it.

EDIT: I noticed I never explicitly stated that my drives get correctly detected (the same way that OP’s do), but every operation like block info or fdisk results in a giant lag which can take even a minute to finish. But the result is correct, it’s just unusable at that point.

7

I doubt that will succeed. My experience is it either works or you have to try another piece of hardware with different chipset that has better support in kernel. Sorry to say that.

8

Yes, I came across this guide and can confirm the kmod drivers are present on my MOX.

At this moment I gave up solution based on the AXAGON EE25-XA6 enclosure and tested 9 other enclosures.

I found out that all the enclosures with USB 3.0 Micro-B SuperSpeed connector were causing headaches.

The winner for me is AXAGON EE25-XA3 with the USB Mini-B connector. Declared speed is of 3Gb/s is OK for my rotational drives. MOX can write 1 GB of data in 12s.

1 Like
9

Oh that’s very interesting. Could you specify what driver gets used for the XA3? Have you tested some read/write speeds? I’m okay with switching to another enclosure as I have more drives sitting around anyway, but I really want to buy one which works with MOX.

EDIT: My enclosure is EE25-S6B, which doesn’t even have a Micro-B connector. I have a feeling that what’s causing the problem are the 6Gig chipsets. 3Gig is still plenty for HDD (>300MB/s which HDDs cannot do).

EDIT2: I’m blind, you’ve already said it. It’s around 85MB/s which is the expected speed for a generic 2.5" HDD. I’m ordering the XA3. Thank you for your help.

10

Alright, I have tried factory reset with minimal kmod-usb-storage-uas drivers, broken for both of my 6Gig JMicron and ASMedia chipsets. I even tried hbt branch (OS 5.0) but it was broken the same way.
I guess MOX is not really usable for any advanced NAS setup, because all of the newer multiple disk enclosures are SATA3. That’s a giant dealbreaker for me and I guess my only option now is selling it.

11

Can you confirm that the enclosures are working fine when connected to the MOX module A?

12

Yes. I’m 100% sure that the ASMedia enclosure gets kmod-usb-storage driver assigned when plugged to A. It’s handled by some secret quirk but it’s clearly visible in the dmesg (I don’t have one in hand at this moment). It worked like that for me from the factory. It’s wierd that quirk works fine for the module A USB but doesn’t do anything for F USBs.

I don’t remember specifically testing the JMicron, because it’s a two bay HDD dock, which is too loud for 24/7 use.

I’m gonna post boot log when I get back to my MOX.

EDIT: Forgot to mention that because of the driver the transfer speed tops out at 45MB/s but it’s tested for 90-110MB/s.

13

Ah OK, so my conclusion that the module A is having USB 2.0 is false. It is just a quirk which is being applied. So in theory the same should be doable for module F…

14

Alright I gathered the vital information:

[   15.817108] usb 5-1: new SuperSpeed USB device number 2 using xhci-hcd
[   15.851268] usb 5-1: USB controller d0058000.usb does not support streams, which are required by the UAS driver.
[   15.861882] usb 5-1: Please try an other USB controller if you wish to use UAS.
[   15.869323] usb-storage 5-1:1.0: USB Mass Storage device detected
[   15.876280] usb-storage 5-1:1.0: Quirks match for vid 174c pid 55aa: 400000
[   15.883810] scsi host1: usb-storage 5-1:1.0
[   16.953481] scsi 1:0:0:0: Direct-Access     WDC WD75 00BPKX-00HPJT0   0    PQ: 0 ANSI: 6
[   16.963046] sd 1:0:0:0: [sdb] 1465149168 512-byte logical blocks: (750 GB/699 GiB)
[   16.970572] sd 1:0:0:0: [sdb] 4096-byte physical blocks
[   16.976713] sd 1:0:0:0: [sdb] Write Protect is off
[   16.981649] sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00
[   16.982059] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   17.086759]  sdb: sdb1

Notice the usb-storage 5-1:1.0: Quirks match for vid 174c pid 55aa: 400000 which “fixes” my ASMedia chipset.

#lsusb
Bus 002 Device 003: ID 1058:1110 Western Digital Technologies, Inc. My Book Essential (WDBAAF), My Book for Mac (WDBAAG)
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0424:2422 Standard Microsystems Corp.
Bus 005 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

#lsusb -t
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M

15

@fortunerayzor Thank you for the update!

So to summarize this:

  • USB storage quirks are applied when the device is connected to the module A
  • The USB storage quirks are NOT applied when the device is connected to the module F
  • Question: How can we apply the USB storage quirks on devices connected to the module F?

@Pepe @ljelinek Can you shed some light on this? I can provide you AXAGON EE25-XA6 for testing if needed.

16

Easiest way to set the quirk for specific USB device in run-time is:

echo "174c:55aa:u" > /sys/module/usb_storage/parameters/quirks

This is specifically a quirk for ASMedia Technology Inc. Name: ASM1051E. The problem is that when the modules are probed during startup of OpenWRT you need the quirk to be present before the module uas is probed. One possibility to do that can be putting appropriate kernel parameter to boot.scr script in /boot. I did this:

th@hroch:~/wip$ cat boot.txt 
if part uuid ${devtype} ${devnum}:${distro_bootpart} partuuid; then
	if test "${bootfstype}" = "btrfs"; then
		rootflags="commit=5,subvol=@"
		subvol="/@"
	else
		rootflags="commit=5"
		subvol=""
	fi

	if load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${subvol}/boot/armada-3720-turris-mox.dtb; then
		has_dtb=1
	else
		setenv has_dtb 0
		echo "Cannot find device tree binary!"
	fi

	if test $has_dtb -eq 1; then
		if load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${subvol}/boot/Image; then
			setenv bootargs "earlyprintk console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 rootfstype=${bootfstype} root=PARTUUID=${partuuid} rootflags=${rootflags} rootwait ${contract} rw cfg80211.freg=${regdomain} usb_storage.quirks=174c:55aa:u"
			booti ${kernel_addr_r} - ${fdt_addr_r}
			echo "Booting Image failed"
		else
			echo "Cannot load kernel binary"
		fi
	fi

	env delete partuuid
fi
th@hroch:~/wip$ mkimage -T script -C none -n boot -d boot.txt boot.scr
Image Name:   boot
Created:      Wed Feb 19 16:50:05 2020
Image Type:   PowerPC Linux Script (uncompressed)
Data Size:    920 Bytes = 0.90 KiB = 0.00 MiB
Load Address: 00000000
Entry Point:  00000000
Contents:
   Image 0: 912 Bytes = 0.89 KiB = 0.00 MiB

And I put the resulting file to MOX image to /boot/boot.scr .

17

… Assuming the usb-storage is compiled in, which is the case with

root@turris:/# uname -a
Linux turris 4.14.162 #0 SMP Thu Jan 16 14:01:28 2020 aarch64 GNU/Linux
18

Thanks @brill!
I will try to apply the modifications you described once I get my hands on the device again.

Questions:

  • Do you think that modification of the boot script needs to be done with every update of the Turris OS?
  • Any idea why the modification is NOT needed when plugging the USB enclosure to the MOX module A?
19

Hi!

  1. Yes, the /boot/boot.scr is a part of mox-support package in TurrisOS. When this package gets updated the script will be overwritten. There is an idea: We can put permanent hook into the boot.scr that would test if there is a dedicated U-Boot environment variable to be inserted into bootargs. I hope that next release could include it. In this case you could either stop U-Boot and set the new variable or you can use

  2. Yes, the XHCI driver for USB3 host in Armada 37xx SoC does not support streams, which is needed for UAS. Therefore UAS is unavailable on the USB3 port on Mox A. It tuned out as another question whether we can word-around it and enable streams on SoC USB3 and it will be investigated.

Cheers,
Tomas