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
Very nice, I don’t think I’ve seen one of those before! I’ve added it to the list and put a note that beta firmware will probably be necessary for anyone buying this in the near future / already has it.
Hi Max. Just saw this message as I’m finally getting back to messing around with my pi. My power supply is a 3.5A CanaKit branded. I got it as part of the kit when I bought my pi4.
Frank Buell
3 years ago
Hi I just received my Deskpi Pro Case from 52Pi and have been testing it. It has an M.2 SSD adapter builtin for Sata drives (non NVME). The design and engineering are great. However I am having issue with performance using a Kingston A400 M.2 SSD. The case is new to the market but I think the choose a poor adapter.
Their web site is brand new without any support or way to leave a question or post a remark. Perhaps you more experience pundits have contacts to reach out to them.
After tweaking I have found that editing the /boot/cmdline file to include “usb-storage.quirks=152d:0562:u” helps to speed up the ssd. But it is still slow.
Your article is a great resource.
Quote: “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 “Verifying Drive Performance” section).”
Results are: Sudo dmesg | grep usb
⋮
[ 1.575361] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 1.606696] usb 2-1: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 1.09
[ 1.606714] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1.606730] usb 2-1: Product: RPi_SSD
[ 1.606746] usb 2-1: Manufacturer: 52Pi
[ 1.606760] usb 2-1: SerialNumber: DD5641988389F
[ 1.610351] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 1.610478] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 1.610497] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 1.610984] usb-storage 2-1:1.0: Quirks match for vid 152d pid 0562: 800000
[ 1.611144] scsi host0: usb-storage 2-1:1.0
sudo hdparm -t --direct /dev/sda #With Quirk set. #Without Quirk set speed was 300kb/sec
/dev/sda:
Timing O_DIRECT disk reads: 476 MB in 3.00 seconds = 158.58 MB/sec
If there is another fix or method to get UAS performance let me know.
My initial thought when I read this was to check if the DeskPi case had flashable/updatable firmware updates available but I wasn’t able to find any. I was able to find people having the exact same issue here and here.
It looks like a lot of people have posted about it already but I don’t see any definitive response. I’m not sure what they can do. If the device doesn’t have any interface or way for the user to update the firmware (pretty common on lower cost things like storage adapters) then the only firmware that could be updated is the Raspberry Pi’s to deal with it. They have done some updates recently to address some issues like this. If you want to try the beta firmware channel to see if the new fixes make a difference with your device check out my firmware guide here.
There *might* be other creative workarounds available but the reason disabling UAS works is that it forces the drive to communicate in a different (slower) mode that doesn’t have whatever “bug” or unexpected/different behavior is making the Pi choke. But I believe these are firmware-level issues which means other than using such workarounds to force it to communicate in a different way and tricks like that I’m not sure anyone can fix them but either the manufacturers of the adapters/enclosures or the Raspberry Pi foundation through Pi firmware updates.
I would see where the conversations go on their GitHub. Almost everything on there is “calling them out” for this issue so they are going to respond eventually I’m sure!
I got the IceX to work. The trick is to put an active USB3 hub in between – with its own power supply. Then the adapter also works on the PI4. I think that the current provided by the PI4 on the USB3.0 port is not high enough. Bonnie++ reports transfer speeds of read 322 MB/s and write 224 MB/s with a SAMSUNG EVO 970.
I also tested the UGREEN M.2 NVMe to USB Enclosure here from the blog. It also runs only with the active hub, not directly connected to my PI4. The transfer speeds here are similar to the IceX enclosure.
Do you have a 3.5A power supply or the standard 3.0A that many Pi kits ship with? I am definitely using a 3.5A in all my action shots that have NVMe drives.
There’s a lot of cheap ones out there that don’t even hit their 3.0A if it’s not a quality one and it leaves nothing to power your drive! Just another option to consider. There is widely varying quality between the adapters.
Note that this only applies to the Pi 4 as any Pi before that couldn’t pass enough current anyways but they bumped up the limits so if you have a larger power supply with your Pi 4 it can pass on the current now!
Mileage may vary by drive. The older it is, the more power it likely uses, but that’s just a guideline and not universally true. I think we are learning though that for NVMe drives that using a powered hub is advisable!
it’s the original Raspberry PI power supply, but only standard 3.0A. Thanks for the tip, I will see if I can get a 3.5A power supply. Then I will test it again with that – and without active USB hub.
I also just wanted to point out that the IceX case does work. Here in this blog it is listed in the chapter “Known Problematic Adapters (Naughty List)” as “ICY BOX M.2 NVMe (M Key) to USB-C 3.1 Gen 2 Enclosure“. If it gets enough power, it does work.
Thanks again for following up with all this great information. I’m really curious what your results will be with the 3.5A with both this and the UGREEN adapter! I’m going to move the ICY BOX up to the works category with your warning that it requires a powered USB hub.
I am still using the SHINESTAR adapter that is in the picture of this article (very thin stick style, and not an enclosure) to this day with a 3.5A. Unfortunately they stopped making these or something because they have been unavailable on Amazon for a while. There’s ones that look extremely similar/identical (probably produced in the same factory) but nobody has reported on one yet so I don’t feel comfortable putting them on here yet one way or another. I don’t have one of the UGREENs or ICY BOXes yet or I would test these myself before you get the 3.5A just to make sure it’s enough for that particular one!
I actually may pick up an ICY BOX because I don’t have an enclosure style NVMe adapter right now and I think that one just looks really cool (superficial I know, but I have like a dozen USB to X adapters and they’re typically quite boring looking). I think it would be fun to try it. The only thing more ridiculous and over the top stylistically would probably be a RGB enclosure (haven’t seen one yet, but wouldn’t be shocked if this exists somewhere).
Possibly we may need to add a stronger warning to most or all NVMe enclosures that you are especially likely you run into power issues with these and that a powered USB hub is strongly recommended or an adapter upgrade may be required!
in the FAQs of raspberry.org you can also find the hint that you should use active USB hubs:
“Very high-demand USB devices may however require the use of a powered hub.”
Unfortunately, I couldn’t find a 3.5A USB power supply on Amazon with a European plug (I am living in Germany), only chargers. The reviews of these chargers state that they do not provide a constant voltage (5V), but rather a constant current. Therefore, they are not suitable for the PI4.
That’s why I have now ordered a 4A power supply unit with Micro-USB plug and an adapter from Micro-USB to USB-C.
At uclock.de you will find a summary of the speeds measured by bonnie++.
Oh wow, I didn’t realize CanaKit wasn’t as easily available over there! I was able to find the charger in a kit on amazon.co.uk but nothing for amazon.de. On amazon.de even the CanaKit kits look like everything is CanaKit and then have some random charger thrown in there with them. I’m guessing they didn’t make a production run of the right wall socket style/wall voltage for over there or didn’t get it certified for those countries yet.
What you’re doing should work fine, and there are some additional options you can consider that I usually don’t recommend but generally work perfectly well. I’ve personally used a Dell laptop USB-C charging cable, a Google Pixel 4a USB-C charger (only rated for 3.0A though so won’t give a boost here), a Samsung Galaxy S20 USB charger and a few others.
People often have ones around the house that will work even if it’s just for a test to see if an overrated power supply will solve the power woes. Sometimes it’s still hard to find one that will put out more than the 3.0A one you have already although sometimes it’s worth testing with another 3.0A anyway as the quality of the output and how much they really do varies widely.
If it’s a high quality USB-C power supply to a reputable brand it should generally be safe to power it. Not everything will work though, here’s a really good Hackaday article that has some of the technical details about why some adapters (like Mac ones) don’t work.
It also talks about how many of these power supplies don’t even hit their rated outputs (extremely common and why I always recommend CanaKit ones, the Canadians have yet to let me down in all these years). I believe the resistors issue was fixed on newer Pi 4 revisions but if you got one of the initial production run Pi 4s (I have one surviving launch Pi 4 left, one of them died, my only Pi to ever die including my 2 original Pi 1s).
The Raspberry Pi 4 is a lot better at passing on this extra current to peripherals than previous generations of Pis were. I believe improved power management/flow is part of the USB-C specification if I remember correctly to improve compatibility. Older Pis could use oversized power adapters but they couldn’t pass on nearly as much power even if it was available.
It sounds like you’ve got a working solution inbound but I wanted to take the chance to link some good work that may help others trying to find a solution as well in the future!
First I tested without NVME adapter by booting the PI4 via SD card. This was successful, everything worked perfectly.
Then I connected the ICY case directly without an active hub and mounted /dev/sda2. That also worked.This behaviour was already better than with the original 3A power supply. But then during the bonnie test, errors appeared in /var/log/messages:
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
sudo dmesg | grep usb:
[ 1.875946] usb 2-1: Product: ASM105x
[ 1.875961] usb 2-1: Manufacturer: ASMT
[ 1.875976] usb 2-1: SerialNumber: 00000000000000000000
What OS and version are you trying to boot? It doesn’t sound like it has new enough firmware on it. Did you create this using the official Raspberry Pi imaging tool? The newest image I see on the site for Raspberry Pi OS is for December 2nd which should have new enough firmware on it but if you didn’t download it very recently it is probably much older than that.
The .dat and .elf files they are referring to can be updated by plugging in the SSD to your Pi on the latest version of Raspbian (fully updated with sudo apt update && sudo apt full-upgrade -y) and then copying the /boot/*.elf and /boot/*.dat files over to your SSD’s “boot” partition. However it’s important that your Raspbian is fully up to date to do this or those firmware files may not be new enough either.
If you plug in the drive and use the following commands (note, you may need to substitute a different drive letter if your drive shows up on the system as something like /dev/sdb instead, see what is plugged in with command lsblk):
This will update those files on the SSD that the error is referring to.
I also wonder if updating to the beta firmware would fix yours. You can try that by doing:
sudo nano /etc/default/rpi-eeprom-update
and changing it from “critical” or “stable” to beta then running:
sudo rpi-eeprom-update -a
followed by a full reboot of your Pi. The new beta versions have fixed some strange issues with adapters and a bunch of other things related to USB mass storage / booting so for something like this it’s worth a shot.
There is one more possibility which is that something is wrong with the firmware itself inside the onboard chip on your Pi (this has happened to a few other people although they had different symptoms). The official Raspberry Pi recovery image created from the Pi Imager tool has fixed a bunch of them so far! It definitely should resolve any bootloader issues if it’s not something related to the image you are using needing updated *.elf and *.dat files. My guide here can help for more detailed instructions!
Jeff
3 years ago
Hello,
Haven’t been back to this post in quite a while (since I got my Pi4 set up after the official USB boot support was added), but I have a quick question about “upgrading” to a larger external SSD…
If I have a running setup booting off the external USB SSD (currently a 120GB PNY), what would be the best way to upgrade to something larger? I am using my pi4 as the main host for a Syncthing setup, and I would like to update to a bigger drive since my 120GB is not enough anymore.
Could I just shut down the Pi, plug the external SSD into a windows PC and use cloning software like Macrium Relfect to clone to another external SSD (the bigger drive)? Or if I don’t have a second USB-SATA adapter, could I image the drive to some free space on my windows desktop internal storage drive and then use that image to create the second larger drive?
I think I have another USB-SATA adapters around here somewhere, but it is one of the models that isn’t well-supported for Pi booting.
Or is there another way to clone the drive directly from the Pi?
And will all of this cloning mess up any of the modifications (like UUID changes) that were made during the process of setting up USB boot in the first place? It doesn’t seem like this would matter if it is a perfect clone of the original, but I am not an expert there…
Well, I just realized that this guide is an updated version for the RasPi4 after the update to allow USB booting. So from reading the above for the first time, it seems that the UUID changes are no longer needed (as they were in the previous guide for booting from SDcard and then using USB for everything else).
But my above question still stands – what is the best method for cloning the existing USB to a new larger one?
Sorry I missed this earlier and you may have already figured this out, but the easiest way is using a GUI partition management tool. I’d say Clonezilla is really good for it. You can also do it on the command line doing dd.
Once you’ve cloned it you would expand the partition table to use the new “free space” on the drive. This is why I was saying to grab one of the popular open source GUI tools to do this is it will take care of all these steps for you!
Frank Meyer
3 years ago
Hi,
First I updated Raspbian, now it shows: Linux pitv 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux
Output of ‘sudo rpi-eeprom-update’:
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Do 3. Sep 12:11:43 UTC 2020 (1599135103)
LATEST: Do 3. Sep 12:11:43 UTC 2020 (1599135103)
FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000138a1
LATEST: 000138a1
The command ‘sudo -E rpi-eeprom-config’
shows only 3 lines: BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
followed by 13 empty lines.
If I call ‘sudo -E rpi-eeprom-config –edit’, nano shows only 3 lines filled with text, I can walk with cursor down also 13 empty lines following. Should I replace the 13 empty lines by the contens you posted above?
Maris tried that here in the replies and it didn’t work but you can see if it will let you save it in there. He got some sort of eeprom timeout error.
Could you give us the output of this command:
vcgencmd bootloader_version
I think the only thing that restored the configuration options was using the Raspberry Pi imaging tool and making the recovery image from that to reset the bootloader. I would give it a try!
Excellent, that looks perfect! I’m surprised how many people have had this issue so far. It seems like even though the bootloader changes are coming out of beta some percentage of people are not having the bootloader configuration update through apt.
The weird thing is the people who have had this always seem to have the right bootloader firmware. It seems like it’s the configuration that won’t update for some reason but restoring using the official Raspberry Pi recovery image has fixed everyone who has experienced this so far.
This works with the “SSK Aluminum M.2 NVME SSD Enclosure Adapter, USB 3.1 Gen 2 (10 Gbps) to NVME PCI-E M-Key Solid State Drive External Enclosure” using the beta firmware. Took me a bit a futzing around and then deciding to try the beta firmware when I was about to give up. This is with Raspian. Going to see if 64-bit Ubuntu 20.10 works also.
pi@raspberrypi:~ $ dmesg | grep "usb 2-2"[ 1.574854] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 1.605972] usb 2-2: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 2.08
[ 1.605990] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1.606007] usb 2-2: Product: SSK Storage
[ 1.606022] usb 2-2: Manufacturer: SSK
[ 1.606038] usb 2-2: SerialNumber: DD564198838D9
pi@raspberrypi:~ $ lsusb
Bus 002 Device 002: ID 152d:0562 JMicron Technology Corp. / JMicron USA Technology Corp.
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
pi@raspberrypi:~ $ sudo rpi-eeprom-update
BCM2711 detected
VL805 firmware in bootloader EEPROM
BOOTLOADER: up-to-date
CURRENT: Tue 24 Nov 2020 03:08:04 PM UTC (1606230484)
LATEST: Thu 03 Sep 2020 12:11:43 PM UTC (1599135103)
FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000138a1
LATEST: 000138a1
pi@raspberrypi:~ $ blkid
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="04A5-3FE5" TYPE="vfat" PARTUUID="1afe17c5-01"
/dev/sda2: LABEL="rootfs" UUID="c1578b06-85c2-4327-9c65-4c474a8f23f9" TYPE="ext4" PARTUUID="1afe17c5-02"
pi@raspberrypi:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 256M 0 part /boot
└─sda2 8:2 0 931.3G 0 part /
Very nice, I don’t think I’ve seen one of those before! I’ve added it to the list and put a note that beta firmware will probably be necessary for anyone buying this in the near future / already has it.
Which power adapter are you using (3.0A or 3.5A) ? Or which usb hub ?
Hi Max. Just saw this message as I’m finally getting back to messing around with my pi. My power supply is a 3.5A CanaKit branded. I got it as part of the kit when I bought my pi4.
Hi I just received my Deskpi Pro Case from 52Pi and have been testing it. It has an M.2 SSD adapter builtin for Sata drives (non NVME). The design and engineering are great. However I am having issue with performance using a Kingston A400 M.2 SSD. The case is new to the market but I think the choose a poor adapter.
Their web site is brand new without any support or way to leave a question or post a remark. Perhaps you more experience pundits have contacts to reach out to them.
After tweaking I have found that editing the /boot/cmdline file to include “usb-storage.quirks=152d:0562:u” helps to speed up the ssd. But it is still slow.
Your article is a great resource.
Quote: “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 “Verifying Drive Performance” section).”
Results are:
Sudo dmesg | grep usb⋮
[ 1.575361] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 1.606696] usb 2-1: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 1.09
[ 1.606714] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1.606730] usb 2-1: Product: RPi_SSD
[ 1.606746] usb 2-1: Manufacturer: 52Pi
[ 1.606760] usb 2-1: SerialNumber: DD5641988389F
[ 1.610351] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 1.610478] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 1.610497] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 1.610984] usb-storage 2-1:1.0: Quirks match for vid 152d pid 0562: 800000
[ 1.611144] scsi host0: usb-storage 2-1:1.0
sudo hdparm -t --direct /dev/sda #With Quirk set. #Without Quirk set speed was 300kb/sec
/dev/sda:
Timing O_DIRECT disk reads: 476 MB in 3.00 seconds = 158.58 MB/sec
If there is another fix or method to get UAS performance let me know.
Hey Frank,
My initial thought when I read this was to check if the DeskPi case had flashable/updatable firmware updates available but I wasn’t able to find any. I was able to find people having the exact same issue here and here.
It looks like a lot of people have posted about it already but I don’t see any definitive response. I’m not sure what they can do. If the device doesn’t have any interface or way for the user to update the firmware (pretty common on lower cost things like storage adapters) then the only firmware that could be updated is the Raspberry Pi’s to deal with it. They have done some updates recently to address some issues like this. If you want to try the beta firmware channel to see if the new fixes make a difference with your device check out my firmware guide here.
There *might* be other creative workarounds available but the reason disabling UAS works is that it forces the drive to communicate in a different (slower) mode that doesn’t have whatever “bug” or unexpected/different behavior is making the Pi choke. But I believe these are firmware-level issues which means other than using such workarounds to force it to communicate in a different way and tricks like that I’m not sure anyone can fix them but either the manufacturers of the adapters/enclosures or the Raspberry Pi foundation through Pi firmware updates.
I would see where the conversations go on their GitHub. Almost everything on there is “calling them out” for this issue so they are going to respond eventually I’m sure!
Your are a wealth of information. Thank you.
In the meantime, I think I will go with the ArgonOne M.2 case. UASP works with that case.
FB
I have not been able to get an IceX case to work.
Mine uses the JMS580 chipset. Its a shame because the casing seems solid.
That definitely is a shame, that’s a great looking enclosure, probably the coolest looking one I’ve seen yet!
Hi,
I got the IceX to work. The trick is to put an active USB3 hub in between – with its own power supply. Then the adapter also works on the PI4. I think that the current provided by the PI4 on the USB3.0 port is not high enough. Bonnie++ reports transfer speeds of read 322 MB/s and write 224 MB/s with a SAMSUNG EVO 970.
I also tested the UGREEN M.2 NVMe to USB Enclosure here from the blog. It also runs only with the active hub, not directly connected to my PI4. The transfer speeds here are similar to the IceX enclosure.
Hope this helps,
Frank
Hey Frank,
Do you have a 3.5A power supply or the standard 3.0A that many Pi kits ship with? I am definitely using a 3.5A in all my action shots that have NVMe drives.
There’s a lot of cheap ones out there that don’t even hit their 3.0A if it’s not a quality one and it leaves nothing to power your drive! Just another option to consider. There is widely varying quality between the adapters.
Note that this only applies to the Pi 4 as any Pi before that couldn’t pass enough current anyways but they bumped up the limits so if you have a larger power supply with your Pi 4 it can pass on the current now!
Mileage may vary by drive. The older it is, the more power it likely uses, but that’s just a guideline and not universally true. I think we are learning though that for NVMe drives that using a powered hub is advisable!
Hi James,
it’s the original Raspberry PI power supply, but only standard 3.0A. Thanks for the tip, I will see if I can get a 3.5A power supply. Then I will test it again with that – and without active USB hub.
I also just wanted to point out that the IceX case does work. Here in this blog it is listed in the chapter “Known Problematic Adapters (Naughty List)” as “ICY BOX M.2 NVMe (M Key) to USB-C 3.1 Gen 2 Enclosure“. If it gets enough power, it does work.
Kind regards,
Frank
Hey Frank,
Thanks again for following up with all this great information. I’m really curious what your results will be with the 3.5A with both this and the UGREEN adapter! I’m going to move the ICY BOX up to the works category with your warning that it requires a powered USB hub.
I am still using the SHINESTAR adapter that is in the picture of this article (very thin stick style, and not an enclosure) to this day with a 3.5A. Unfortunately they stopped making these or something because they have been unavailable on Amazon for a while. There’s ones that look extremely similar/identical (probably produced in the same factory) but nobody has reported on one yet so I don’t feel comfortable putting them on here yet one way or another. I don’t have one of the UGREENs or ICY BOXes yet or I would test these myself before you get the 3.5A just to make sure it’s enough for that particular one!
I actually may pick up an ICY BOX because I don’t have an enclosure style NVMe adapter right now and I think that one just looks really cool (superficial I know, but I have like a dozen USB to X adapters and they’re typically quite boring looking). I think it would be fun to try it. The only thing more ridiculous and over the top stylistically would probably be a RGB enclosure (haven’t seen one yet, but wouldn’t be shocked if this exists somewhere).
Possibly we may need to add a stronger warning to most or all NVMe enclosures that you are especially likely you run into power issues with these and that a powered USB hub is strongly recommended or an adapter upgrade may be required!
Hi James,
in the FAQs of raspberry.org you can also find the hint that you should use active USB hubs:
“Very high-demand USB devices may however require the use of a powered hub.”
Unfortunately, I couldn’t find a 3.5A USB power supply on Amazon with a European plug (I am living in Germany), only chargers. The reviews of these chargers state that they do not provide a constant voltage (5V), but rather a constant current. Therefore, they are not suitable for the PI4.
That’s why I have now ordered a 4A power supply unit with Micro-USB plug and an adapter from Micro-USB to USB-C.
At uclock.de you will find a summary of the speeds measured by bonnie++.
Oh wow, I didn’t realize CanaKit wasn’t as easily available over there! I was able to find the charger in a kit on amazon.co.uk but nothing for amazon.de. On amazon.de even the CanaKit kits look like everything is CanaKit and then have some random charger thrown in there with them. I’m guessing they didn’t make a production run of the right wall socket style/wall voltage for over there or didn’t get it certified for those countries yet.
What you’re doing should work fine, and there are some additional options you can consider that I usually don’t recommend but generally work perfectly well. I’ve personally used a Dell laptop USB-C charging cable, a Google Pixel 4a USB-C charger (only rated for 3.0A though so won’t give a boost here), a Samsung Galaxy S20 USB charger and a few others.
People often have ones around the house that will work even if it’s just for a test to see if an overrated power supply will solve the power woes. Sometimes it’s still hard to find one that will put out more than the 3.0A one you have already although sometimes it’s worth testing with another 3.0A anyway as the quality of the output and how much they really do varies widely.
If it’s a high quality USB-C power supply to a reputable brand it should generally be safe to power it. Not everything will work though, here’s a really good Hackaday article that has some of the technical details about why some adapters (like Mac ones) don’t work.
It also talks about how many of these power supplies don’t even hit their rated outputs (extremely common and why I always recommend CanaKit ones, the Canadians have yet to let me down in all these years). I believe the resistors issue was fixed on newer Pi 4 revisions but if you got one of the initial production run Pi 4s (I have one surviving launch Pi 4 left, one of them died, my only Pi to ever die including my 2 original Pi 1s).
The official Raspberry Pi 3.0A power supply is known to deliver more than 3.0A as well but I don’t think it delivers as much as the CanaKit 3.5A one.
The Raspberry Pi 4 is a lot better at passing on this extra current to peripherals than previous generations of Pis were. I believe improved power management/flow is part of the USB-C specification if I remember correctly to improve compatibility. Older Pis could use oversized power adapters but they couldn’t pass on nearly as much power even if it was available.
Here’s a bunch of other people doing this here (bottom of thread has the newer 2019 posts) and a lengthier StackExchange discussion here.
It sounds like you’ve got a working solution inbound but I wanted to take the chance to link some good work that may help others trying to find a solution as well in the future!
Hi James,
my 4 A power supply unit has arrived.
First I tested without NVME adapter by booting the PI4 via SD card. This was successful, everything worked perfectly.
Then I connected the ICY case directly without an active hub and mounted /dev/sda2. That also worked.This behaviour was already better than with the original 3A power supply. But then during the bonnie test, errors appeared in /var/log/messages:
Dec 23 11:00:23 raspberrypi kernel: [ 296.819105] sd 0:0:0:0: [sda] tag#17 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD INDec 23 11:00:23 raspberrypi kernel: [ 296.819125] sd 0:0:0:0: [sda] tag#17 CDB: opcode=0x28 28 00 00 25 22 e0 00 01 00 00
Dec 23 11:00:23 raspberrypi kernel: [ 296.929109] sd 0:0:0:0: [sda] tag#18 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
Dec 23 11:00:23 raspberrypi kernel: [ 296.929127] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x28 28 00 00 25 23 e0 00 01 00 00
Dec 23 11:00:27 raspberrypi kernel: [ 301.299178] sd 0:0:0:0: [sda] tag#19 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD
Dec 23 11:00:27 raspberrypi kernel: [ 301.299197] sd 0:0:0:0: [sda] tag#19 CDB: opcode=0x2a 2a 00 00 38 24 18 00 00 10 00
Dec 23 11:00:27 raspberrypi kernel: [ 301.339195] scsi host0: uas_eh_device_reset_handler start
Dec 23 11:00:27 raspberrypi kernel: [ 301.490250] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 23 11:00:27 raspberrypi kernel: [ 301.524697] scsi host0: uas_eh_device_reset_handler success
Meanwhile, the write rate has dropped from 230 MB/s to 90 MB/s.
Finally, I tried to boot the PI4 from the ICY adapter. The boot got stuck.
Conclusion: It does not work without an active USB hub.
P.S.
I tested this with a new PI4, which does not have the error on the USB-C port that the early PI4s had (missing resistor).
Hi James,
Getting an error trying to boot my 4B 4GB from a OCZ Vertex 2 SATA II 240GB with a non powered BENFI USB 3.0 adapter. Boot up just loops.
My bootloader config is:
BOOT_UART=0WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41
Error is:
USB - MSD boot requires newer softwarehttps://www.raspberrypi.org/software/
ERROR: 00000044
Missing/empty 'fixup4rc.dat'
Your thoughts?
Info on the USB 3.0 adapter:
sudo lsusb:
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 bridgesudo dmesg | grep usb:
[ 1.875946] usb 2-1: Product: ASM105x[ 1.875961] usb 2-1: Manufacturer: ASMT
[ 1.875976] usb 2-1: SerialNumber: 00000000000000000000
Hey Larry,
What OS and version are you trying to boot? It doesn’t sound like it has new enough firmware on it. Did you create this using the official Raspberry Pi imaging tool? The newest image I see on the site for Raspberry Pi OS is for December 2nd which should have new enough firmware on it but if you didn’t download it very recently it is probably much older than that.
The .dat and .elf files they are referring to can be updated by plugging in the SSD to your Pi on the latest version of Raspbian (fully updated with sudo apt update && sudo apt full-upgrade -y) and then copying the /boot/*.elf and /boot/*.dat files over to your SSD’s “boot” partition. However it’s important that your Raspbian is fully up to date to do this or those firmware files may not be new enough either.
If you plug in the drive and use the following commands (note, you may need to substitute a different drive letter if your drive shows up on the system as something like /dev/sdb instead, see what is plugged in with command lsblk):
sudo mkdir /mnt/boot
sudo mount /dev/sda1 /mnt/boot
sudo cp /boot/*.dat /mnt/boot
sudo cp /boot/*.elf /mnt/boot
sudo umount /mnt/boot
This will update those files on the SSD that the error is referring to.
I also wonder if updating to the beta firmware would fix yours. You can try that by doing:
sudo nano /etc/default/rpi-eeprom-updateand changing it from “critical” or “stable” to beta then running:
sudo rpi-eeprom-update -afollowed by a full reboot of your Pi. The new beta versions have fixed some strange issues with adapters and a bunch of other things related to USB mass storage / booting so for something like this it’s worth a shot.
There is one more possibility which is that something is wrong with the firmware itself inside the onboard chip on your Pi (this has happened to a few other people although they had different symptoms). The official Raspberry Pi recovery image created from the Pi Imager tool has fixed a bunch of them so far! It definitely should resolve any bootloader issues if it’s not something related to the image you are using needing updated *.elf and *.dat files. My guide here can help for more detailed instructions!
Hello,
Haven’t been back to this post in quite a while (since I got my Pi4 set up after the official USB boot support was added), but I have a quick question about “upgrading” to a larger external SSD…
If I have a running setup booting off the external USB SSD (currently a 120GB PNY), what would be the best way to upgrade to something larger? I am using my pi4 as the main host for a Syncthing setup, and I would like to update to a bigger drive since my 120GB is not enough anymore.
Could I just shut down the Pi, plug the external SSD into a windows PC and use cloning software like Macrium Relfect to clone to another external SSD (the bigger drive)? Or if I don’t have a second USB-SATA adapter, could I image the drive to some free space on my windows desktop internal storage drive and then use that image to create the second larger drive?
I think I have another USB-SATA adapters around here somewhere, but it is one of the models that isn’t well-supported for Pi booting.
Or is there another way to clone the drive directly from the Pi?
And will all of this cloning mess up any of the modifications (like UUID changes) that were made during the process of setting up USB boot in the first place? It doesn’t seem like this would matter if it is a perfect clone of the original, but I am not an expert there…
Thanks!
Well, I just realized that this guide is an updated version for the RasPi4 after the update to allow USB booting. So from reading the above for the first time, it seems that the UUID changes are no longer needed (as they were in the previous guide for booting from SDcard and then using USB for everything else).
But my above question still stands – what is the best method for cloning the existing USB to a new larger one?
Thanks again!
Hey Jeff,
Sorry I missed this earlier and you may have already figured this out, but the easiest way is using a GUI partition management tool. I’d say Clonezilla is really good for it. You can also do it on the command line doing dd.
Once you’ve cloned it you would expand the partition table to use the new “free space” on the drive. This is why I was saying to grab one of the popular open source GUI tools to do this is it will take care of all these steps for you!
Hi,
First I updated Raspbian, now it shows:
Linux pitv 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/LinuxOutput of ‘sudo rpi-eeprom-update’:
BCM2711 detectedDedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Do 3. Sep 12:11:43 UTC 2020 (1599135103)
LATEST: Do 3. Sep 12:11:43 UTC 2020 (1599135103)
FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000138a1
LATEST: 000138a1
The command ‘sudo -E rpi-eeprom-config’
shows only 3 lines:
BOOT_UART=0WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
followed by 13 empty lines.
If I call ‘sudo -E rpi-eeprom-config –edit’, nano shows only 3 lines filled with text, I can walk with cursor down also 13 empty lines following. Should I replace the 13 empty lines by the contens you posted above?
Hey Frank,
Maris tried that here in the replies and it didn’t work but you can see if it will let you save it in there. He got some sort of eeprom timeout error.
Could you give us the output of this command:
vcgencmd bootloader_versionI think the only thing that restored the configuration options was using the Raspberry Pi imaging tool and making the recovery image from that to reset the bootloader. I would give it a try!
Hi James,
$ vcgencmd bootloader_versionSep 3 2020 13:11:43
version c305221a6d7e532693cc7ff57fddfc8649def167 (release)
timestamp 1599135103
Kind regards
Frank
Hi James,
I loaded the recovery image and now the output of rpi-eeprom-config is fine:
[all]BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41
Thank you very much!
Regards
Frank
Hey Frank,
Excellent, that looks perfect! I’m surprised how many people have had this issue so far. It seems like even though the bootloader changes are coming out of beta some percentage of people are not having the bootloader configuration update through apt.
The weird thing is the people who have had this always seem to have the right bootloader firmware. It seems like it’s the configuration that won’t update for some reason but restoring using the official Raspberry Pi recovery image has fixed everyone who has experienced this so far.
Thanks for letting us know it worked out!
Hi James,
Meanwhile I connected a USB3.1 to SATA adapter from Poppstar and copied the SD as image to an older 2.5″ SATA disk. The boot worked fine. 🙂
bonnie++ gives a speed of 99MB/sec for block transfer – both reading and writing. I am very happy with that… it’s an old HDD.
Now I installed another brand new RPI4 with the latest PI OS and then updated it – as described here in this blog.
The same issue exists here as well:
sudo -E rpi-eeprom-config’ shows only 3 lines:
BOOT_UART=0WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
But now I know how to fix this problem 🙂
Next I will test the boot of M.2 NVME SSD…
Thank you!
Frank
Thank you for this great resource!
I spent 5 hours trying to boot from an SSD using a Vantec CB-STU3-2PB, and had nothing but problems.
I found your page, switched to my StarTech/ASMedia ASM1051E, and was up and running in less than 30 seconds.
You can add the Vantec to your “Known problems” list. I tried the quirks setting, but it didn’t help for this one.
Thanks Moshe Katz, I’ve added this to the naughty list!