Force UASP support

I have a hdd enclosure, that has worked for me with UASP on, but I was using raspibolt. I’ve just “upgraded” to raspiblitz to make installation of stuff a bit easier.

The issue is that I am not confident that my testing is enough. Especially because in my testing, the HDD is about 2 - 3 inches away from the pi. Sounds unimportant, but I found that the wifi was not working properly when it was right under the pi with UASP on.

On top of that, my SSD runs MUCH slower with UASP off. Enough that I’ve wasted a whole week getting half the blocks to download and now that I have it on, there is a very noticable difference.

Long story short, I think it is a good idea to have a way for people like myself to force UASP to be enabled. I am not sure the best way to go about it right now.

My initial thought was to add a variable to the raspiblitz.info file, but I realised that the datadrive.sh file does not source this file so I am open to ideas. I didn’t want to add a source of this file to the script because it might break something else, but I do want to ensure that my contribution is “fool proof” or at least robust.

I want a solution that will not require patching after a raspiblitz upgrade in the future.

[rootzoll]

At the moment the RaspiBlitz is checking the the type of the ssd-driver/enclosure and just for models we know & tested the the UASP support kept on … for every other its deactivated to prevent the bug reports we had on RaspBlitzes freezing during sync.

@dipunm because this UASP detection is done during the first boot on a fresh system, it would make sense to use the tweak of putting a file like uasp.force on the boot section of the sd card with your laptop after flashing the sd card before putting it into the RaspberryPi. This could be detected and UASP will stay on. BUT I think then also a entry in the raspiblitz.conf should be created in that process automatically so that on an update/recovery with a fresh sd card this can be re-fixed again without the need of adding again the uasp.force file to the sd card manually.

As you can see this is quite a bit of implementation todo. I will keep this for the v1.8.1 milestone in mind … but if anybody likes to contribute a PR on this we might consider this earlier.

[cricktor]

I purchased the same specified UGREEN enclosure from the README.md and it has the vendor and device ID 174c:1153 with the bridge chip ASM1153.

admin@raspiblitz:~ $ lsusb
Bus 002 Device 002: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
...

I did some brief testing with RaspiBlitz v1.7.1 and didn’t experience trouble with UAS mode, so I enforced UAS mode with touch /boot/uasp.force, removed the usb-storage quirk entry in /boot/cmdline.txt and added a similar if-statement to whitelist this particular enclosure in the file config.scripts/blitz.datadrive.sh (maybe not necessary, when /boot/uasp.force is in place):

    # check if HDD ADAPTER is on UASP WHITELIST (tested devices)
    if [ "${hddAdapter}" == "174c:55aa" ]; then
      # UGREEN 2.5" External USB 3.0 Hard Disk Case with UASP support
      hddAdapterUSAP=1
    fi
    if [ "${hddAdapter}" == "174c:1153" ]; then
      # UGREEN 2.5" External USB 3.0 Hard Disk Case with UASP support, 2021+ version
      hddAdapterUSAP=1
    fi
    if [ "${hddAdapter}" == "0825:0001" ] || [ "${hddAdapter}" == "174c:0825" ]; then
      # SupTronics 2.5" SATA HDD Shield X825 v1.5
      hddAdapterUSAP=1
    fi
    echo "hddAdapterUSAP=${hddAdapterUSAP}"

admin@raspiblitz:~ $ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
...

With UAS mode in place the Sandisk Plus SSD is properly recognized as a non-HDD (/sys/block/sda/queue/rotational is zero, despite with usb-storage quirk mode it reads as 1). I was also able to activate TRIM according to instructions summarized specifically in Jeff’s blog post https://www.jeffgeerling.com/blog/2020/enabling-trim-on-external-ssd-on-raspberry-pi To make the provisioning mode unmap persistant, I added the file /etc/udev/rules.d/10-trim.rules with content

ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="1153", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

I feel better now for my SSD because I believe that proper TRIM handling allows the SSD controller to do a better wear leveling job. So far my RaspiBlitz runs happily and I didn’t recognize any severe issues in the log files. Keep rockin’n’rollin’!