The new Raspberry Pi 4 bootloader has finally come out of beta and made it’s way into the official latest Raspbian! This has been long awaited since when the Raspberry Pi 4 was released it had no native support for booting from USB / Network but it was promised right from the start it would get it through a later update.
This guide will show how to configure the new bootloader and set up your Pi to boot from USB devices as well as the other boot options now available within the Raspberry Pi 4 bootloader.
The Samsung 980 Pro (NVMe) is a professional grade SSD and one of the fastest in the world. The Samsung NVMe drives have been at the top of this category for a long time and are well trusted for both their performance and reliability / long life.
The ICY BOX is basically a giant heatsink that you mount a high performance M.2 NVMe drive inside of. This enclosure is really fast but requires a powered USB hub. Not even the 3.5A adapter can reliably power it! The enclosure works well and will physically feel warm to the touch as it is pulling the heat off your NVMe drive!
The Kingston A400 has been a great drive to use with the Pi for years. It’s reliable, widely available around the world, has low power requirements and performs very well. It’s also very affordable. This drive has been benchmarked over 1000 times at pibenchmarks.com and is the #1 most popular SSD among the Pi community!
The USB 3.1 variant of the StarTech 2.5″ SATA adapter works well with the Pi 4. The USB 3.0 variant doesn’t have firmware updates available and is not recommended.
The SanDisk Extreme A1-A2 SD card has the best scoring SD card on pibenchmarks.com for years and is second in popularity only to the SanDisk Ultra (often included in combo kits). The application class (A1) means random I/O speeds (very important when running an OS) have to meet a higher standard. There’s no benefit on the Pi for A2 right now so get whichever is cheaper/available.
You may use other types of drives with the Pi such as M.2 SATA to USB 3.0 and m-SATA to USB 3.0. Here’s some adapters I’ve used for those types of drives:
UGREEN M+B Key M.2 Enclosure
The UGREEN M+B enclosure is a great enclosure for the Pi for M.2 SATA 2280 NGFF drives. It supports both B-key and M-key drives. Does not support newer NVMe drives. As with other types of enclosures it requires more power than other options!
The VL716 mSATA enclosure lets you connect micro SATA drives to the Pi. These drives are an older type of SSD (usually seen in laptops) predating the M.2 slot but are still widely available and perform extremely well!
Another option for M.2 SATA (not NVMe) is to use the Argon One Pi case:
Argon ONE Pi 4 M.2 Case
The Argon ONE M.2 is a M.2 SATA Pi 4 case / storage solution. With the case and M.2 SATA expansion board you can completely enclosure your Pi 4 and have a built in M.2 slot! The M.2 SATA board is sometimes sold separately from the case itself and can be used as well. Does not support NVMe, this is for SATA M.2 drives only!
Power can be a serious problem with these drives. We are learning from the comments that you are especially likely to run into power issues with NVMe enclosures. A powered USB hub or a power adapter that puts out 3.5A comes not only just strongly recommended, it may actually be required that you choose one option or the other for your drive to function.
The specific requirements of how much power you’ll need depend on the adapter/enclosure and the model of your drive itself. As a very rough guideline, older models of drives tend to use more power than newer models of drives. 3.5″ form factor drives also use more power than 2.5″ drives. The earliest SSD models like first and second generation models are also well understood to use significantly more power than newer models. This is due to changes and improvements in technology over the years and even using different more efficient memory like 3D NAND. Some super high end performance drives will consume more power as well.
Here’s the current recommendations based on everyone’s comments combined with stuff I’ve personally used with the Pi:
CanaKit 3.5A Power Adapter
The CanaKit 3.5A adapter has an extra half an amp (500 mA) of capacity to give some breathing room to your accessories. This is bigger than the official Pi power supply which provides 3.0A.
The Sabrent powered USB hub delivers a whopping 2.5A of dedicated power for your USB attached devices. This is almost as much as the Pi adapter itself is rated for (3.0A). It will easily power the most thirsty of setups such as NVMe enclosures.
Note: Make sure Amazon doesn’t try to take you to the non-powered version and that it’s the one with the AC adapter that plugs in to provide extra power
The new USB-C 3.1 Type A version of the Sabrent adapter is reported as working in the comments by UEF. DO NOT get the USB 3.0 version as that one is below on the naughty list and won’t work!
Make absolutely sure it’s the 10Gbps USB 3.1 Gen 2 version. There is another one that looks identical that is a USB 3.1 Gen 2 6Gbps that will not work. Confirmed working by RRT in the comments.
It’s bold. It’s beautiful. It’s also confirmed working by TADRACKET and Steve B. However, be warned, it takes a *lot* of power! Steve B. reports that even with the oversized 3.5A CanaKit adapter* it does not work. If you have the standard 3.0 adapter you can be practically certain it won’t power this enclosure. Does work with a powered USB hub*.
Returning legendary commentary Frank Meyer reports: Does not work with a 3.0A power adapter (also reported by TTE). It’s not enough power for this enclosure. Does work with a powered USB hub*.
M.Yusuf has given the first ever report of a working Orico adapter! Make sure it’s the USB 3.1 Gen 2 version that says “Support UASP for NVMe SSD”. This is the way.
Canakit has been making very reliable power supplies for several Pi generations now. Using a 3.5A power supply will give enough extra power for your Pi to power the drive without causing instability
Reported as working by JeffG but with an ugly messy appearance
Known Working Adapters
Known Problematic Adapters (Naughty List)
Here is a list of common USB adapters that are known to have problems with the Raspberry Pi 4. You can get some of these adapters working by using quirks mode (see the “Fix (some) USB Adapter Problems Using Quirks” section below).
Only works in the USB 2.0 ports. Will not boot in a USB 3.0 port. I have two of these and can confirm they don’t work. RIP to Sabrent, our previous king of the Pi 3 era of adapters.
Despite earlier reports as working Ryan and one other have reported this adapter does not work unless you enable quirks mode! Don’t make Ryan’s sacrifice in vain and avoid this one.
Extremely cheap adapter from AliExpress — MADATALIEXPRESS bought 5 of them and none worked, PPCM had one working, very unreliable and slow when it does work, not recommended even if you get lucky!
To edit the bootloader configuration you should have a copy of Raspbian on a SD card. Right now support in third party operating systems to do anything with the new Raspberry Pi 4’s firmware or bootloader is very limited / nonexistent. You can use a third party operating system later once you set the boot mode, but to actually make these changes we will use official Raspbian.
First make sure that you have the absolute latest updates and firmware for the Pi. To upgrade all your packages and firmware to the latest version use the following command:
sudo apt update && sudo apt full-upgrade -y
Once the update has completed restart your Pi with a sudo reboot command to apply the latest firmware / kernel updates.
Verify EEPROM Bootloader is up to date
We can check if your Pi’s bootloader firmware is up to date with the following command:
sudo rpi-eeprom-update
If your Raspbian is *very* out of date you may not have this utility and can install it using:
sudo apt install rpi-eeprom
The output from rpi-eeprom-update will look like this if you are not up to date:
BCM2711 detected
VL805 firmware in bootloader EEPROM
*** UPDATE AVAILABLE ***
BOOTLOADER: update available
CURRENT: Thu 3 Sep 12:11:43 UTC 2020 (1599135103)
LATEST: Tue 24 Nov 15:08:04 UTC 2020 (1606230484)
FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000138a1
LATEST: 000138a1
If it says any updates are available they be installed manually by adding ‘-a’ to the end of our previous command like this:
sudo rpi-eeprom-update -a
After the updates finish installing restart your Pi as firmware updates will not be applied until after a reboot. Now if you run rpi-eeprom-update to check for updates again it should say you are on the latest and up to date!
Verify Power Supply Size (3.5A strongly recommended)
Check your Raspberry Pi’s power supply size and make sure it is delivering at least 3.5A. There are a lot of USB C adapters for the Raspberry Pi that are only 3.0A. These will typically work fine, until you plug in something like a SSD which draws power from the Pi and there is nothing left to give.
Most SSDs are quite power efficient but HDDs draw significantly more. Older generations of SSDs used quite a bit more power than newer ones as well. If you are using an older drive or a drive that you know is power hungry you need to pay extra attention to having a quality power source with plenty of capacity.
A good alternative option to relying on the Pi to power the drive is using a powered USB hub* so your drive doesn’t need to draw power from the Pi’s limited power budget. Make sure you get one that is compatible with the Pi as some powered USB hubs won’t work properly with it so check the reviews and do your research to make sure people are using it successfully with the Pi.
Image your bootable drive (your SSD / HDD / USB Flash Drive / etc.) the same way you imaged your micro SD card. You write the image of the operating system you want to run to the disk with Etcher / Win32DiskImager / however you normally would write one.
Once this is finished we are ready to edit the bootloader configuration to tell it to boot to our drive instead of the built in microSD slot.
If you’ve completed the prerequisites you are now ready to edit your Raspberry Pi’s bootloader configuration to tell the Pi to boot from a specified device instead of the built in microSD slot. To edit the bootloader configuration use the following command:
Our target is the BOOT_ORDER parameter in bold above. It is 0x1 in firmware versions up until 2020-05-150 and was changed to 0xf41 (try SD card first, then boot from USB if that fails) in newer versions after that. Here are the different configuration options for the BOOT_ORDER parameter (from Raspberry Pi documentation):
Stop and display error pattern (since 2020-09-03). A power cycle is required to exit this state.
0xf
RESTART
Start again with the first boot order field. (since 2020-09-03)
Raspberry Pi 4 USB BOOT_ORDER Options
The configuration option we want is USB mass storage device boot or option 0x4. We can use this option by itself or combine it with other options in the table placed in the order we want the Pi to try to boot from. To understand how to do this, let’s examine the default Raspberry Pi OS value of 0xf14. The values are read from right to left so this value means it will try USB booting first and then fall back to SD storage next.
If you want to leave the SD card and the “restart on failure” fallback options in place you can change it to 0xf14 (remember, the order is from right to left). Go ahead and use your arrow keys to navigate to the BOOT_ORDER line and change it 0x4 or 0xf14 so it reads:
BOOT_ORDER=0x4
or
BOOT_ORDER=0xf14 (to enable falling back to SD card if USB boot fails)
This translates to attempt to boot from USB mass storage first. If that fails, try to boot from SD card. If that fails, start over from step 1 and try again (back to USB mass storage). As another example, if you wanted to add booting from the network you could add the 0x2 value from the table for the “NETWORK” option and make it the final BOOT_ORDER value 0xf124. If you wanted to change the order so that the network boots first instead you could reorder it to 0xf142.
Choose the appropriate BOOT_ORDER you would like and use your arrow keys to move down to the BOOT_ORDER line. Change the line and press Control+X and then ‘y’ to save your changes. Make sure you have your boot device we set up in the prerequisites section plugged into one of the blueUSB ports as these ports are USB 3.0 and the black USB ports are USB 2.0 (slower). Now restart the Pi.
If all went well the Pi will immediately boot up from your boot device instead of the SD card!
Help, something went wrong!
Try Booting from SD card
Generally if the Pi fails to boot from the USB device it will fall back to booting from the SD card. If the Pi didn’t boot after making the change try unplugging your USB device and just booting from the SD card again by removing power from the Pi and plugging it back in again.
If the device is booting fine from the SD card but not from the external drive double check that you have a compatible adapter and that the drive was imaged correctly. Plug it into a PC and make sure it has the files on it and perhaps try giving it a clean image again just in case something went wrong with imaging the first time.
Verify rpi-eeprom-config configuration
Make sure your changes that we made earlier actually stuck by verifying the configuration using the command:
sudo -E rpi-eeprom-config --edit
and verify that the BOOT_ORDER=0x1 line is changed to BOOT_ORDER=0x4.
Restore Bootloader to Defaults
If things are *really* broken and the Pi will not boot at all with your SD card or otherwise then you may need to restore the bootloader back to defaults.
To do this we need to prepare a SD card with the Raspberry Pi 4 EEPROM boot recovery tool. The easiest way to do this is to use the official Raspberry Pi Imager tool from the Raspberry Pi foundation to prepare the recovery image.
Here is how we create the recovery image inside the utility. Choose the “Misc utility images” category as shown below:
Raspberry Pi Imager Step #1
Next choose the “Raspberry Pi 4 EEPROM boot recovery” option:
Raspberry Pi Imager Step #2
Next choose your SD card and then choose “Write”. Now unplug your Pi and put in the newly prepared SD card. Connect the power and let it boot. This will restore your bootloader to defaults. You should see a continuous rapid green blinking light. You may now disconnect the power and put your original SD card back / reinstall Raspbian and boot the Pi normally!
The beta firmware released since the original USB mass storage device support launched contains a bunch of fixes related to USB mass storage devices and USB booting. The downside is the beta firmware is not as well tested so you shouldn’t install it unless you are doing it to fix a specific issue addressed in those updates.
To switch to the beta channel edit the configuration file with the following command:
sudo nano /etc/default/rpi-eeprom-update
Change the line FIRMWARE_RELEASE_STATUS=”critical” (sometimes it can be “stable”) to:
FIRMWARE_RELEASE_STATUS="beta"
Now press Ctrl+X and then ‘y’ to save our changes in nano. Now execute a Pi firmware update using:
sudo rpi-eeprom-update -a
The updater will tell you whether updates were applied or not. Now do a full reboot of your Pi as the firmware updates won’t be applied until you do! If you want to switch back to normal firmware simply change the configuration back to “stable” or “critical”.
Verify Drive Performance
You can make sure everything is running correctly (and as fast as it should be) by running my quick storage benchmark. You can run the benchmark with the following one-liner:
This will give you a score you can compare to the other Raspberry Pi Storage Benchmark results and make sure that you are getting an equivalent speed to your peers with the same device!
Fix (some) USB Adapter Problems Using Quirks
Some of the very common adapters on the naughty list above (such as the Sabrent) can be made to work by using USB quirks to disable UAS mode on the drive. This lowers performance, but it’s still much faster than a SD card and your adapter won’t go to waste.
To find out the quirks we need to find the device ID string for your adapter and then add an entry to cmdline.txt telling the kernel to apply them on boot.
Find Your Adapter
To apply the quirks we first need to get the adapter id. We will use the sudo lsusb command:
$ sudo lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 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 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
On line 2 we can see my ASM1051E SATA 6Gb/s bridge adapter (it’s the known working StarTech.com 2.5″ SATA to USB 3.1* adapter). You will see something very similar to mine when you run the command and it shouldn’t be too hard to figure out which device it is. If you need more information add a -v switch to make the command sudo lsusb -v. This can sometimes add some additional details to make it easier to figure out which one is your adapter.
If you’re still not sure, we have another command that between the two that can narrow things down. Type / paste the following:
sudo dmesg | grep usb
[0.828535] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[0.828568] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[0.828597] usb usb3: Product: DWC OTG Controller
[0.828620] usb usb3: Manufacturer: Linux 4.19.75-v7l+ dwc_otg_hcd
[0.828644] usb usb3: SerialNumber: fe980000.usb
[0.830051] usbcore: registered new interface driver uas
[0.830182] usbcore: registered new interface driver usb-storage
[0.836488] usbcore: registered new interface driver usbhid
[0.836511] usbhid: USB HID core driver
[0.971598] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[1.154217] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
[1.154254] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[1.154281] usb 1-1: Product: USB2.0 Hub
[1.301989] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[1.332965] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
[1.332999] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[1.333026] usb 2-1: Product: ASM105x
[1.333048] usb 2-1: Manufacturer: ASMT
[1.333071] usb 2-1: SerialNumber: 123456789B79F
This is the dmesg log showing the hardware detection as hardware is activated on the Pi. If your log is really long you can generate fresh entries by just unplugging a device and plugging it back in and running the command again. Here we can clearly see that the ASM105x is what our StarTech adapter is being detected as.
Now we can go back to our first lsusb command and we want the 8 characters from the ID field that comes right after the Device:
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge
Our adapter’s ID is: 174c:55aa
Applying Quirks
To apply the quirks to our USB adapter we are going to edit /boot/cmdline.txt. Type:
sudo nano /boot/cmdline.txt
We are going to add the following entry into the very front of cmdline.txt:
usb-storage.quirks=XXXX:XXXX:u
In place of the X’s above you will put in your adapter’s ID that we got before. With the example commands I gave above mine would look like this: usb-storage.quirks=174c:55aa:u. After this my cmdline.txt looks like this (everything should be one continuous line, no line breaks!):
Now reboot the Pi. If the Pi fails to boot you can plug the SD card into the computer and go to /boot/cmdline.txt and undo the change we did so you can boot back in with your SD card.
Verifying Quirks
Once you have rebooted after changing cmdline.txt we can verify the quirks have been applied by doing another dmesg | grep usb command:
sudo dmesg | grep usb
[1.332924] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
[1.332957] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[1.332983] usb 2-1: Product: ASM105x
[1.333006] usb 2-1: Manufacturer: ASMT
[1.333028] usb 2-1: SerialNumber: 123456789B79F
[1.335967] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[1.336071] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[1.336103] usb-storage 2-1:1.0: USB Mass Storage device detected
[1.336479] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c00000
[1.336611] scsi host0: usb-storage 2-1:1.0
This time we can see in dmesg that UAS was blacklisted for the device and it has loaded with the usb-storage driver instead. This driver tends to be more compatible with the “problematic adapters” but the performance is usually significantly lower. It’s definitely worth a try though as some adapters do better with the quirks performance-wise. The only way to know for sure is to run a benchmark (see “Verify Drive Performance” section).
If you want to see which Pi storage performs the fastest and get an idea of what kind of drives to look for check out my 2022 Raspberry Pi Storage Benchmarks
273 thoughts on “Raspberry Pi 4 Bootloader USB Mass Storage Boot Guide”
Henny
Hello,
Is the Ugreen USB3.1 C Gen 2 usable with a WD green 240 Gb sata ssd a usable and working combinatie with a new PI 4B
It has a ASM235CM chip.
Thanks for any answer
Greetz
Have you had issues booting from USB3 device when there’s more than one device plugged into a USB3 slot?
I have two SanDisk 1TB Extreme Portable SSD that I can not boot from if they are both plugged in to USB3. If either is plugged in alone it boots. I can boot from both if plugged into the USB2 plugs, but of course that’s much slower.
Actually I can’t boot from just one if I also have my keyboard plugged into the USB3 plug so it seem that at boot time I can have only one USB3 device plugged in.
To be clear, this seems to be a hardware issue; I’m not seeing any signs of an operating system during my problem boot attempts.
It’s a bit annoying because booting requires a visit to the PI in my basement.
The main things to check are that you have your Pi EEPROM bootloader firmware up to date which I’m guessing you’ve already done if you followed this guide. Another thing that is helpful though is to check for firmware updates for your individual devices like storage adapters / USB drives / etc. as sometimes they have firmware updates available. There are cases of USB chipset incompatibilities and other things like that that people in the comments here have applied and been able to successfully boot with after that.
I think you are having a different issue though, especially after what you said about not being able to plug in a keyboard with it either. There isn’t enough power available to power both of those devices through the Pi. It sounds like with the external keyboard plugged in there isn’t enough power left available for the drive as it puts you close enough to the 1.2A limit built into the Pi that it won’t boot reliably.
Basically there’s likely nothing that would stop all these from working together but the Pi can only provide a limited amount of total power and the limit is shared between *all* plugged in devices combined together unfortunately. On the Raspberry Pi 4 that is a total of 1.2A of maximum amount of power allowed to pass through the Pi to the USB devices. You can read more about the limits here.
The way around this is to get a powered USB hub. The hub bypasses the maximum 1.2A power limit for all of your devices combined since it has it’s own AC adapter. A oversized 3.5A power supply can sometimes help but if you’re trying to plug in multiple drives you are definitely going to need a powered USB hub for that since the Pi can’t pass enough power for them to function. Sometimes the oversized power adapter isn’t even enough for the Pi to power a single NVMe enclosure like one of the fancy LED ones to give an idea of how little power 1.2A can be with some types of devices.
For multiple drives definitely grab a powered USB hub for sure. Hopefully that helps!
Turns out the problem was with the custom u-boot I was using. I upgraded that custom u-boot and now I can boot with several devices plugged into USB3 ports.
Now I can boot from a pair of ZFS-mirrored USB3 drives (without manual intervention)!
That’s a fantastic outcome! I have suspected that some of the other boot issues that people have reported here are due to custom versions of u-boot implemented in various other projects across the landscape and always figured they probably just need a u-boot upgrade. Thanks for letting us know your outcome!
I bought the ORICO USB 3.1 Gen1 Type-C to SATA Dual-Bay Hard Drive Docking Station. I followed all the steps for updates to EEPROM and ignored the warning to avoid Orico. Glad I did, because this docking station has worked flawlessly for a week so far; fast, silent, and looks cool too! Plus I can make disk to disk backups without even using the RPi4B 8GB. (I have not tried a disk copy yet…I will wait until I get a spare 120GB SSD!)
I don’t think I’d seen this particular one before, but I have heard that the firmware updates can get some of these Orico enclosures working. It sounds like yours worked out of the box though after updating your Pi’s EEPROM. Thanks for the heads up, and let us know what your SSD testing yields!
Thanks for letting us know your specifics. I definitely agree with you and have been giving stronger and stronger warnings about power when using NVMe enclosures every time I edit/update these articles!
I’ve only had one NVMe adapter that didn’t require additional power and that was the QNINE stick style ones (not enclosures). They have no LEDs of any kind and are just basically a bare board with a USB connection that you set the M2 on. The only problem with these is that NVMe drives do get really really hot (which can reduce their lifespan and even cause them to fail if it gets hot enough) and the newer enclosures like the ICY BOX, the Rog Strix enclosure, etc. all have ways to pull heat off the drive to give you reliable long term operation. The ICY BOX is basically a giant heatsink and you’ll be surprised how warm to the touch it gets pulling heat off my Samsung NVMe high performance drives!
Can’t connect with Raspberry Pi4 Channels-DVR (USB Boot Image) setup web site. Tried imaging it on Micro SD 32GB card, a 256 GB USB stick, and a Toshiba 2TB external box.
A monitor connected to the Raspberry finishes the install at a “{OK}Started Update UTMP about System Runlevel Changes. Green Light is Solid. Attempting to connect to httx://IPaddress:8089 or httx://drv-server:8089 or httx://drv-server.local:8089 from a Win10 Pro workstation and Android X86 box-Google app, all fail to find the server.
Built the Raspberry Pi with both 32 bit and 64 bit OS downloads. Installed Channels-DVR using curl -f -s https://getchannels.com/dvr/setup.sh | sh command. Again temped to setup from Win10 using same url’s, No Go. Opening the setup from Raspberry desktop could not setup ECG connection to cable company. Failed login, using same login as used to cable company web site, and connect when running Channels-DVR on a Win10 system. Cable company tech support next to useless, do not support Linux, limited support for TV Anywhere (because 3rd party SW). Did verify Channels-DVR/TV Anywhere usage authorized in cable profile.
Other symptoms—
Monitor will blank out for a second then return to same screen, almost like a loose connection but triple verified.
Started up an Android TV box that has TV Anywhere installed (on after restarting Win10 system). The screen said to configure the Raspberry Channels-DRV using web interface. Redirected to Win10 IP address and worked fine.
Till the Android box I though the Pi was not broadcasting or allowing external connections. Maybe I’m fighting a different problem on both setups. Looking for ideas on fixing either setup. Not Linux literate but learning.
This is the first time I have heard of this one! It definitely looks like it should support it and their support article is pretty recent (October of last year). Did you set it up using rpi-imager per these instructions?
Rpi-imager can definitely fix a lot of issues that occur vs. writing the image with Etcher/Rufus/etc. There’s so many weird obscure issues the rpi-imager tool fixes with drives/partitioning that are very difficult to find (or even know to look for) otherwise so that is always worth a try. I also recommend wiping the drive completely of all partitions (delete the entire partition table so it’s completely blank, nothing on it) as I have seen this fix some weird, weird stuff before with partitioning that even rpi-imager hasn’t fixed before!
Your “Started Update UTMP about System Runlevel Changes. Green Light is Solid” almost sounds like a freeze/kernel panic to me. If you Google that error message you can see people getting that all over different Linux distros and the problem usually ends up being something like the drive has errors and needs an fsck, the drive is failing, etc. Do you have any other spare drives to test with to rule this out?
I did see this here where it sounds like the headless image has nothing to really see which seems to create some confusion. You should still be able to connect with the browser like you were trying to do though so I think you may be looking at a crash/kernel panic or this should still work.
This is a really tough one. It could even be networking related since Windows has some sneaky tricks to resolve hostnames that won’t work in Linux without additional configuration/packages to add mdns4 support. Definitely let us know what you find!
I’ve bought a Startech 2.5″ adapter using the AliExpress link, doesn’t work at all.
When checking the information it turned out not to be StarTech but some other brand..
Three adapters down.. none working so far. (at least not stable)
That is very annoying. I did some researching after your tip and found other people in the reviews saying that this AliExpress seller is basically lying about it being a StarTech. Please leave them one as well if you wouldn’t mind. I’m going to pull the link for that one down immediately!
Which other ones have you tried? Were they also AliExpress? Sorry about that, it’s difficult when sellers are completely misrepresenting their product/brand while trying to provide international links and I appreciate you letting me know!
The other one was a AliExpress Generic 2.5″ SATA to USB 3.0 3 colors Hard Disk Case*
That seemed to work when applying quirks and a powered USB hub, but it kind of collapsed after some time.
First symptom was panels failing in HA, after that numerous read / write error messages on the terminal screen.
This was after applying quirks.
I’ve now bought a CSL – USB 3.0 SSD/SATA Adaptor Converter for SSD which turns out to be plug and play. No quirks required, just copied a fresh HA on, restored a snapshot and it’s running.
That’s for a couple of hours now (can cheer to early 😉
I add to my previous comment that my ADWITS USB 3.0 UASP to SATA NGFF M.2 enclosure containing a WD Green 240 GB Internal SSD M.2 SATA had previously been able to boot my older RPI4 2gb when directly plugged into its USB3 ports. But on my new RPI4 4gb it would not work when directly plugged into the pi, though as mentioned it would work when attached via an ANKER powered USB3 hub (but not the Sabrent powered hub 🙁
Does the Pi actually power on when you try to boot using the Sabrent? A really common problem with the powered USB hubs is that the Pi can draw power from your USB hub. The Pi is detecting power from the hub so it’s trying to boot using that power (instead of your USB-C power cable) but the Sabrent hub can’t give it nearly enough power to boot.
The Sabrent one definitely does this and I actually haven’t found a good widely available one that doesn’t backfeed power yet. I almost think there has to be like a $3 USB power filter or something we could stick on the end of it so that the Pi does not try to do this.
There’s another simple fix where you can remove the 5V line from that cable that goes from your hub to the Pi. You can do this with a tiny bit of silver insulation tape or by actually cutting the wire. I definitely need to try this so you have inspired me to do this experiment with my Sabrent and write a more updated guide but there’s a pretty good guide on this here. It’s a little dated but should still apply.
Which Anker hub/model are you using? I’m really curious as this may be worth adding to my recommendations. I’m seeing several on Amazon and some of these have like 36W power adapters which would almost certainly explain why it works on those. The Sabrent hub provides much less extra power than that and is nothing even close to 36W which is enough to power several Pis and accessories! My guess is that the hub is literally able to power your Pi because it has a large enough power bank or you would have this exact same issue as well. Back in the day I used to power Pis off of USB hubs (Pi 1 and 2 days). Your Pi will probably work even if you remove the USB-C power cable if the Anker hub really is providing enough power to run it.
On my Pi 400 which boots from a ICY BOX connected to the Sabrent USB 3.0 hub is I actually unplug the hub’s USB cable and then connect my Pi’s power and immediately reconnect the powered USB hub. Then it will boot up normally and find the SSD and boot off it and I’m curious if yours will do the same!
Hi James, thanks for your info. The Anker powered hub I used is over 6 years old now – its a 4-port usb 3.0 hub model number H4928-U3. When the rpi is off and I plug in the ADWITS a blue light on the ADWITS lights up but not the light on the Anker. When I power the rpi though the usb-c port, the rpi red and green lights come on and the Anker blue light flashes a few times and then goes steady and after a bit of blue light flashing on the ADWITS we are booted up.
When using the Sabrent, when the ADWITS is inserted and the Sabrent button is press to power up the USB3 ports the ADWITS blue light lights up. When the power is applied to the rpi USB-C port the rpi red led lights up, but no rpi green light and no booting. So you must be correct about the Sabrent also putting power into the rpi usb3 port which is upsetting the pi. I was not aware that this was possible and it seems its possible of damage the from the voltage/current from the usb source. I’ll have a go at either snipping a few wires or more likely getting a couple of usb3 breakout boards and making sure that the 5v is not connected to the output on this concoction that connects to the rpi.
It sounds like you’re on the right track. I just published an article I had been working on for the past week today but I definitely want to experiment with this more. I think the silver tape mod is the most promising and just covering the 5V pin inside the Sabrent’s USB-A connector!
The Anker’s behavior is pretty interesting. It definitely sounds like it’s still backfeeding power or making some kind of connection (intentional or unintentional)! For some reason it doesn’t seem to trigger the Pi’s boot sequence like the Sabrent does which only requires a momentary interruption of that connection to get going. Is the drive still being powered by the hub as well when you did your test with the Pi off? I feel like it shouldn’t even know it’s plugged in to an offline device and it makes me wonder if power is flowing from the hub through the drive to the Pi itself! It doesn’t sound like it’s enough to get it to attempt to boot like the other hubs.
Let us know how it turns out when you can experiment more!
Hi James,
I did try unplugging the Sabrent from the pi, then booting the pi and immediately connecting the Sabrent to the pi, but this did not work for me.
Regarding the Anker the ‘powered’ usb3 ports are not switched so the device gets power as soon as its plugged in. But the hub to computer lead does not back feed any power it seems. I found this web page, probably out of date, but it does list some hubs that do not back feed.
I would also note that I power my pi from an alternative power source not from the Anker usb hub.
Thanks for the info about the hub! I used to have some of the USB 2.0 hubs on that list for the Raspberry Pi 1 for this very reason! I couldn’t find any hubs that were still in production on that site for USB 3.0. The Anker one at the top was one I was really hoping to find but it looks like that was like 3 models ago.
I’m guessing the tape thing is going to be the way to go to eliminate having to unplug it yet but I haven’t bothered with mine since it’s easy to just briefly unplug it and it fires right up. I’m not sure what is going on with the Sabrent hub as it has been a long favorite for years. I’m almost wondering if it’s defective!
I haven’t really heard anyone concerned about the backfeed for a while other than it being annoying when the Pi tries to boot from it. Any discussions related to it happened years ago like this and the consensus was always that it was harmless.
I ordered a roll of electrical tape since I didn’t have any here and it should be coming Saturday and I will give the electrical mod a try!
Hi James,
I got my hands on a usb3 female breakout board. I tested the Sabrent USB plug that goes to the pi and got out the multimeter. I was expecting to find 5.xx volts between its vbus and ground pins. But no! there was only Zero volts. I tried to find a voltage from any combination of its pins, with and without a usb item plugged into one of its powered ports and the power switch activated. Theres a nice steady 5.13 Volts available on the power ports when they are switched on, but I do not get any power from the hub to the pi. A usb memory stick worked ok any of the ‘power’ usb ports when they were switched on. I don’t have a suitable way to measure the current draw these power ports can provide. So I don’t think that power backfeed is the issue.
Fantastic discoveries! I did some more digging after your information and you’re right, there’s a lot more going on here. Check out this Pi forums post.
The problem is all these cheap 4 port USB 3 hubs that you find on both eBay and Amazon are very poorly designed. The external 5V is connected to both Upstream and Downstream VBUS which causes confusion in the Raspberry Pi USB controller and the back powering problems. It has been suggested to cut the red cable (VBUS Upstream) between the Pi and the USB hub, however this is only half the job
This is really interesting. It looks like the power backfeed is part of the problem on some hubs but it’s not the whole story:
I have found that just cutting the red cable with my connected Hard Drives the Pi would randomly not recognised the attached Drives or not see the Drives after a reboot. I have also found that the Hard Drives would not reset or enter standby after a reboot leaving the Drives in a active state.
The only way was to send a software reset to the USB hub or disconnect and reconnect the Drive for the Pi to see the Drives which is a right pain.
This is really similar to the behavior I’m getting. If I reboot the Pi I have to do the disconnect trick but it sounds like there’s actually a way to send a software reset command to the USB hub which is interesting. Now for the good part:
The way round this problem is to disconnect the Pi Upstream VBUS Red Cable and connect it to the reset circuit of the USB Hub Controller chip. The USB Hubs I have been using have either a GL3510 or GL3520 Controller chip and both the external 5V rail and the Upstream VBUS are both connected to the reset circuit, so there is no way of resetting the Controller chip by lowering the Upstream VBUS. You need to lift one end of R1 disconnecting that end from the external 5V rail and solder the Pi Upstream VBUS cable to the other end of R1.
Amiga-Quantum52 on the Raspberry Pi forums calls this the USB VBUS mod. I bolded the part that I think explains this. Your Anker hub must not have the the external 5V rail and the upstream VBUS connected to the reset circuit but apparently this is exceedingly rare to actually find in production (and from what I can tell, yours is no longer in production either)!
It sounds like power backfeed may not be the issue at all on the Sabrent hub (considering your measurements you took) and that it’s the way the VBUS is wired (improperly and against the USB spec according to many in this thread) in these cheap hubs. Not a single person in this thread could name a single one other than the PiHut one that actually works correctly though and when I searched their site for powered USB 3.0 hubs I came up with nothing in my initial search.
I’ll have to crack open the Sabrent hub and take a look at the internals here (I do have a soldering iron) but this is fascinating information. I think we’re getting really close to some answers here, answers that are frankly extremely difficult to find and it looks like the fix won’t be super easy such as just a piece of tape!
Hello,
Is the Ugreen USB3.1 C Gen 2 usable with a WD green 240 Gb sata ssd a usable and working combinatie with a new PI 4B
It has a ASM235CM chip.
Thanks for any answer
Greetz
Have you had issues booting from USB3 device when there’s more than one device plugged into a USB3 slot?
I have two SanDisk 1TB Extreme Portable SSD that I can not boot from if they are both plugged in to USB3. If either is plugged in alone it boots. I can boot from both if plugged into the USB2 plugs, but of course that’s much slower.
Actually I can’t boot from just one if I also have my keyboard plugged into the USB3 plug so it seem that at boot time I can have only one USB3 device plugged in.
To be clear, this seems to be a hardware issue; I’m not seeing any signs of an operating system during my problem boot attempts.
It’s a bit annoying because booting requires a visit to the PI in my basement.
Hey Hōkan,
The main things to check are that you have your Pi EEPROM bootloader firmware up to date which I’m guessing you’ve already done if you followed this guide. Another thing that is helpful though is to check for firmware updates for your individual devices like storage adapters / USB drives / etc. as sometimes they have firmware updates available. There are cases of USB chipset incompatibilities and other things like that that people in the comments here have applied and been able to successfully boot with after that.
I think you are having a different issue though, especially after what you said about not being able to plug in a keyboard with it either. There isn’t enough power available to power both of those devices through the Pi. It sounds like with the external keyboard plugged in there isn’t enough power left available for the drive as it puts you close enough to the 1.2A limit built into the Pi that it won’t boot reliably.
Basically there’s likely nothing that would stop all these from working together but the Pi can only provide a limited amount of total power and the limit is shared between *all* plugged in devices combined together unfortunately. On the Raspberry Pi 4 that is a total of 1.2A of maximum amount of power allowed to pass through the Pi to the USB devices. You can read more about the limits here.
The way around this is to get a powered USB hub. The hub bypasses the maximum 1.2A power limit for all of your devices combined since it has it’s own AC adapter. A oversized 3.5A power supply can sometimes help but if you’re trying to plug in multiple drives you are definitely going to need a powered USB hub for that since the Pi can’t pass enough power for them to function. Sometimes the oversized power adapter isn’t even enough for the Pi to power a single NVMe enclosure like one of the fancy LED ones to give an idea of how little power 1.2A can be with some types of devices.
For multiple drives definitely grab a powered USB hub for sure. Hopefully that helps!
Thank you, James, for your response.
Turns out the problem was with the custom u-boot I was using. I upgraded that custom u-boot and now I can boot with several devices plugged into USB3 ports.
Now I can boot from a pair of ZFS-mirrored USB3 drives (without manual intervention)!
Hey Hōkan,
That’s a fantastic outcome! I have suspected that some of the other boot issues that people have reported here are due to custom versions of u-boot implemented in various other projects across the landscape and always figured they probably just need a u-boot upgrade. Thanks for letting us know your outcome!
I bought the ORICO USB 3.1 Gen1 Type-C to SATA Dual-Bay Hard Drive Docking Station. I followed all the steps for updates to EEPROM and ignored the warning to avoid Orico. Glad I did, because this docking station has worked flawlessly for a week so far; fast, silent, and looks cool too! Plus I can make disk to disk backups without even using the RPi4B 8GB. (I have not tried a disk copy yet…I will wait until I get a spare 120GB SSD!)
Hey Richard,
I don’t think I’d seen this particular one before, but I have heard that the firmware updates can get some of these Orico enclosures working. It sounds like yours worked out of the box though after updating your Pi’s EEPROM. Thanks for the heads up, and let us know what your SSD testing yields!
So I got one of the ORICO NVMe enclosures with UASP support (ORICO M2PV-C3-BK-EP) and it worked immediately and nicely but it would lock up in a day or two, and sometimes in 14 hours with high CPU and high disk access.
I moved it to a USB powered hub and works fine with no lockups at all.
My conclusion is that I don’t think any of those NVMe USB enclosures can work without a USB powered hub unless your Pi is idle all the time.
Hey Scorpius,
Thanks for letting us know your specifics. I definitely agree with you and have been giving stronger and stronger warnings about power when using NVMe enclosures every time I edit/update these articles!
I’ve only had one NVMe adapter that didn’t require additional power and that was the QNINE stick style ones (not enclosures). They have no LEDs of any kind and are just basically a bare board with a USB connection that you set the M2 on. The only problem with these is that NVMe drives do get really really hot (which can reduce their lifespan and even cause them to fail if it gets hot enough) and the newer enclosures like the ICY BOX, the Rog Strix enclosure, etc. all have ways to pull heat off the drive to give you reliable long term operation. The ICY BOX is basically a giant heatsink and you’ll be surprised how warm to the touch it gets pulling heat off my Samsung NVMe high performance drives!
I’m glad you got everything working, take care!
Can’t connect with Raspberry Pi4 Channels-DVR (USB Boot Image) setup web site. Tried imaging it on Micro SD 32GB card, a 256 GB USB stick, and a Toshiba 2TB external box.
A monitor connected to the Raspberry finishes the install at a “{OK}Started Update UTMP about System Runlevel Changes. Green Light is Solid. Attempting to connect to
httx://IPaddress:8089orhttx://drv-server:8089orhttx://drv-server.local:8089from a Win10 Pro workstation and Android X86 box-Google app, all fail to find the server.Built the Raspberry Pi with both 32 bit and 64 bit OS downloads. Installed Channels-DVR using
curl -f -s https://getchannels.com/dvr/setup.sh | shcommand. Again temped to setup from Win10 using same url’s, No Go. Opening the setup from Raspberry desktop could not setup ECG connection to cable company. Failed login, using same login as used to cable company web site, and connect when running Channels-DVR on a Win10 system. Cable company tech support next to useless, do not support Linux, limited support for TV Anywhere (because 3rd party SW). Did verify Channels-DVR/TV Anywhere usage authorized in cable profile.Other symptoms—
Monitor will blank out for a second then return to same screen, almost like a loose connection but triple verified.
Started up an Android TV box that has TV Anywhere installed (on after restarting Win10 system). The screen said to configure the Raspberry Channels-DRV using web interface. Redirected to Win10 IP address and worked fine.
Till the Android box I though the Pi was not broadcasting or allowing external connections. Maybe I’m fighting a different problem on both setups. Looking for ideas on fixing either setup. Not Linux literate but learning.
Hey Tom,
This is the first time I have heard of this one! It definitely looks like it should support it and their support article is pretty recent (October of last year). Did you set it up using rpi-imager per these instructions?
Rpi-imager can definitely fix a lot of issues that occur vs. writing the image with Etcher/Rufus/etc. There’s so many weird obscure issues the rpi-imager tool fixes with drives/partitioning that are very difficult to find (or even know to look for) otherwise so that is always worth a try. I also recommend wiping the drive completely of all partitions (delete the entire partition table so it’s completely blank, nothing on it) as I have seen this fix some weird, weird stuff before with partitioning that even rpi-imager hasn’t fixed before!
Your “Started Update UTMP about System Runlevel Changes. Green Light is Solid” almost sounds like a freeze/kernel panic to me. If you Google that error message you can see people getting that all over different Linux distros and the problem usually ends up being something like the drive has errors and needs an fsck, the drive is failing, etc. Do you have any other spare drives to test with to rule this out?
I did see this here where it sounds like the headless image has nothing to really see which seems to create some confusion. You should still be able to connect with the browser like you were trying to do though so I think you may be looking at a crash/kernel panic or this should still work.
This is a really tough one. It could even be networking related since Windows has some sneaky tricks to resolve hostnames that won’t work in Linux without additional configuration/packages to add mdns4 support. Definitely let us know what you find!
I’ve bought a Startech 2.5″ adapter using the AliExpress link, doesn’t work at all.
When checking the information it turned out not to be StarTech but some other brand..
Three adapters down.. none working so far. (at least not stable)
Hey Yvo Tuk,
That is very annoying. I did some researching after your tip and found other people in the reviews saying that this AliExpress seller is basically lying about it being a StarTech. Please leave them one as well if you wouldn’t mind. I’m going to pull the link for that one down immediately!
Which other ones have you tried? Were they also AliExpress? Sorry about that, it’s difficult when sellers are completely misrepresenting their product/brand while trying to provide international links and I appreciate you letting me know!
The other one was a AliExpress Generic 2.5″ SATA to USB 3.0 3 colors Hard Disk Case*
That seemed to work when applying quirks and a powered USB hub, but it kind of collapsed after some time.
First symptom was panels failing in HA, after that numerous read / write error messages on the terminal screen.
This was after applying quirks.
I’ve now bought a CSL – USB 3.0 SSD/SATA Adaptor Converter for SSD which turns out to be plug and play. No quirks required, just copied a fresh HA on, restored a snapshot and it’s running.
That’s for a couple of hours now (can cheer to early 😉
I add to my previous comment that my ADWITS USB 3.0 UASP to SATA NGFF M.2 enclosure containing a WD Green 240 GB Internal SSD M.2 SATA had previously been able to boot my older RPI4 2gb when directly plugged into its USB3 ports. But on my new RPI4 4gb it would not work when directly plugged into the pi, though as mentioned it would work when attached via an ANKER powered USB3 hub (but not the Sabrent powered hub 🙁
Hey bg,
Does the Pi actually power on when you try to boot using the Sabrent? A really common problem with the powered USB hubs is that the Pi can draw power from your USB hub. The Pi is detecting power from the hub so it’s trying to boot using that power (instead of your USB-C power cable) but the Sabrent hub can’t give it nearly enough power to boot.
The Sabrent one definitely does this and I actually haven’t found a good widely available one that doesn’t backfeed power yet. I almost think there has to be like a $3 USB power filter or something we could stick on the end of it so that the Pi does not try to do this.
There’s another simple fix where you can remove the 5V line from that cable that goes from your hub to the Pi. You can do this with a tiny bit of silver insulation tape or by actually cutting the wire. I definitely need to try this so you have inspired me to do this experiment with my Sabrent and write a more updated guide but there’s a pretty good guide on this here. It’s a little dated but should still apply.
Which Anker hub/model are you using? I’m really curious as this may be worth adding to my recommendations. I’m seeing several on Amazon and some of these have like 36W power adapters which would almost certainly explain why it works on those. The Sabrent hub provides much less extra power than that and is nothing even close to 36W which is enough to power several Pis and accessories! My guess is that the hub is literally able to power your Pi because it has a large enough power bank or you would have this exact same issue as well. Back in the day I used to power Pis off of USB hubs (Pi 1 and 2 days). Your Pi will probably work even if you remove the USB-C power cable if the Anker hub really is providing enough power to run it.
On my Pi 400 which boots from a ICY BOX connected to the Sabrent USB 3.0 hub is I actually unplug the hub’s USB cable and then connect my Pi’s power and immediately reconnect the powered USB hub. Then it will boot up normally and find the SSD and boot off it and I’m curious if yours will do the same!
Hi James, thanks for your info. The Anker powered hub I used is over 6 years old now – its a 4-port usb 3.0 hub model number H4928-U3. When the rpi is off and I plug in the ADWITS a blue light on the ADWITS lights up but not the light on the Anker. When I power the rpi though the usb-c port, the rpi red and green lights come on and the Anker blue light flashes a few times and then goes steady and after a bit of blue light flashing on the ADWITS we are booted up.
When using the Sabrent, when the ADWITS is inserted and the Sabrent button is press to power up the USB3 ports the ADWITS blue light lights up. When the power is applied to the rpi USB-C port the rpi red led lights up, but no rpi green light and no booting. So you must be correct about the Sabrent also putting power into the rpi usb3 port which is upsetting the pi. I was not aware that this was possible and it seems its possible of damage the from the voltage/current from the usb source. I’ll have a go at either snipping a few wires or more likely getting a couple of usb3 breakout boards and making sure that the 5v is not connected to the output on this concoction that connects to the rpi.
Hey bg,
It sounds like you’re on the right track. I just published an article I had been working on for the past week today but I definitely want to experiment with this more. I think the silver tape mod is the most promising and just covering the 5V pin inside the Sabrent’s USB-A connector!
The Anker’s behavior is pretty interesting. It definitely sounds like it’s still backfeeding power or making some kind of connection (intentional or unintentional)! For some reason it doesn’t seem to trigger the Pi’s boot sequence like the Sabrent does which only requires a momentary interruption of that connection to get going. Is the drive still being powered by the hub as well when you did your test with the Pi off? I feel like it shouldn’t even know it’s plugged in to an offline device and it makes me wonder if power is flowing from the hub through the drive to the Pi itself! It doesn’t sound like it’s enough to get it to attempt to boot like the other hubs.
Let us know how it turns out when you can experiment more!
Hi James,
I did try unplugging the Sabrent from the pi, then booting the pi and immediately connecting the Sabrent to the pi, but this did not work for me.
Regarding the Anker the ‘powered’ usb3 ports are not switched so the device gets power as soon as its plugged in. But the hub to computer lead does not back feed any power it seems. I found this web page, probably out of date, but it does list some hubs that do not back feed.
I would also note that I power my pi from an alternative power source not from the Anker usb hub.
Hey bg,
Thanks for the info about the hub! I used to have some of the USB 2.0 hubs on that list for the Raspberry Pi 1 for this very reason! I couldn’t find any hubs that were still in production on that site for USB 3.0. The Anker one at the top was one I was really hoping to find but it looks like that was like 3 models ago.
I’m guessing the tape thing is going to be the way to go to eliminate having to unplug it yet but I haven’t bothered with mine since it’s easy to just briefly unplug it and it fires right up. I’m not sure what is going on with the Sabrent hub as it has been a long favorite for years. I’m almost wondering if it’s defective!
I haven’t really heard anyone concerned about the backfeed for a while other than it being annoying when the Pi tries to boot from it. Any discussions related to it happened years ago like this and the consensus was always that it was harmless.
I ordered a roll of electrical tape since I didn’t have any here and it should be coming Saturday and I will give the electrical mod a try!
Hi James,
I got my hands on a usb3 female breakout board. I tested the Sabrent USB plug that goes to the pi and got out the multimeter. I was expecting to find 5.xx volts between its vbus and ground pins. But no! there was only Zero volts. I tried to find a voltage from any combination of its pins, with and without a usb item plugged into one of its powered ports and the power switch activated. Theres a nice steady 5.13 Volts available on the power ports when they are switched on, but I do not get any power from the hub to the pi. A usb memory stick worked ok any of the ‘power’ usb ports when they were switched on. I don’t have a suitable way to measure the current draw these power ports can provide. So I don’t think that power backfeed is the issue.
Hey bg,
Fantastic discoveries! I did some more digging after your information and you’re right, there’s a lot more going on here. Check out this Pi forums post.
This is really interesting. It looks like the power backfeed is part of the problem on some hubs but it’s not the whole story:
This is really similar to the behavior I’m getting. If I reboot the Pi I have to do the disconnect trick but it sounds like there’s actually a way to send a software reset command to the USB hub which is interesting. Now for the good part:
Amiga-Quantum52 on the Raspberry Pi forums calls this the USB VBUS mod. I bolded the part that I think explains this. Your Anker hub must not have the the external 5V rail and the upstream VBUS connected to the reset circuit but apparently this is exceedingly rare to actually find in production (and from what I can tell, yours is no longer in production either)!
It sounds like power backfeed may not be the issue at all on the Sabrent hub (considering your measurements you took) and that it’s the way the VBUS is wired (improperly and against the USB spec according to many in this thread) in these cheap hubs. Not a single person in this thread could name a single one other than the PiHut one that actually works correctly though and when I searched their site for powered USB 3.0 hubs I came up with nothing in my initial search.
I’ll have to crack open the Sabrent hub and take a look at the internals here (I do have a soldering iron) but this is fascinating information. I think we’re getting really close to some answers here, answers that are frankly extremely difficult to find and it looks like the fix won’t be super easy such as just a piece of tape!