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”
Carto
Thanks for this guide James.
Do you have plans to update your guide for RPi4 Ubuntu now that the Raspberry Pi 4 Bootloader USB is out of beta? I hope this will make the setup for Ubuntu easier.
I am obviously missing something. Executing the ‘sudo -E rpi-eeprom-config –edit’ command loads a file ‘/tmp/tmpmf8ua9ol/boot.conf’ into nano.
The contents of the file : BOOT_UART=0
WAKE_ON-GPIO=1
POWER_OFF_ON_HALT=0
Adding the BOOT_LOADER params and saving (ctrl-X, Y with same file name) returns : ‘ERROR : rpi-eeprom-update -d -i -f /tmp/tmpjj_1frdu/pieeprom.upd timeout’.
Hmmm, that doesn’t look quite right, it looks like an old configuration from before the USB boot support was added. Can you try restoring the bootloader to defaults using a:
sudo rpi-eeprom-update -a -d
Also when you said you were having a dependency issue is your apt package manager still functioning correctly? You may want to do a
Very curious. You are missing a lot of options. Check out the Raspberry Pi bootloader configuration page from the Raspberry Pi docs. Every configuration entry has a date from when it was added. Were the original 3 you posted the only ones in there still? That would date you all the way back to a 2019-07-15 bootloader configuration. Even the first one released in 2020 has additional options!
You should be able to update the firmware from Raspbian on a SD card. It won’t matter that you use the SSD again later since the firmware is stored on a chip. Do you have a spare SD card you could try from with a fresh Raspbian image to rule out the SSD/adapter? I haven’t encountered this before. I almost wonder if your bootloader is locked somehow or being overridden through some of the options that are in the link I posted in the first paragraph potentially?
Using the full blown official Raspberry Pi firmware/bootloader recovery image (see the “Restoring Bootloader to Defaults” section to see screenshots of this) may be in order potentially as well. What do you get from using the command:
Noting that I try seems to make any difference. vcgencmd bootloader_config returns the same three options as before as does the rpi-eeprom-update -a -d command.
I vaguely recall having timing issues with the 860EVO when I tried SSD boot a while ago (year?).
I ordered the same set-up that you describe above and I’ll attempt it again.
The weird thing is that the SSD should have nothing to do with it. That bootloader configuration on the Pi 4 is stored on a chip inside the Pi. The vcgencmd utility is essentially relaying the actual bootloader settings that the Pi is using directly from the SoC. I was hoping it was some kind of bug with the edit command and that it wasn’t your actual configuration but that definitely seems to confirm it.
Have you tried using the recovery image yet? Which SSD / SD card you use won’t make any difference. The bootloader is lower level than that. I know you said you reflashed, does that mean you used the official recovery image? And just to confirm, and I thought I said this somewhere in your older posts but now I’m not sure, this is a Pi 4? Because this won’t work for anything older than a 4 as they don’t have this bootloader.
The updated boot loader via vcgencmd bootloader_config 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
However :
This is the same error stream I got using Spiess’ youtube (#312) technique. On boot after diddling the SSD for 10 mins. :
Timed out waiting for device /dev/serial1
Dependency failed for Configure Bluetooth Modems connected by UART
Timed out waiting for device /dev/disk/by-portuuid/58ce116e-01
Dependency failed for /boot
…
and stop
That looks much better! At least your bootloader is functioning and correctly configured again. Everything I can find related to that error points to the partition UUID not matching your /etc/fstab file.
The Samsung 860 EVO is the 9th most popular SSD by number of submissions with over 322 benchmarks so far. I think the drive will be fine. The adapter is probably the culprit.
One other thing you should check is to try having the Raspberry Pi imaging tool create the SSD media for you. This would be the same tool you created the recovery image with. Have you tried that yet by chance? I only say this because I’ve seen some imaging tools mess up those PartUUIDs before so it may be worth giving a shot while you’re waiting!
Jon
I seem to have the same issues as Maris. I’m using a Qnine NMVe adapter with a Toshiba drive. My rpi-eeprom-update output and looks identical to his except my specified FW DIR is to the /stable directory rather than /critical. My rpi-eeprom-config file looks identical to his as well with the BOOT_ORDER=0xf41 rather than your example of just 0x4.
The thing that suck out to me looking at the difference between the update outputs was that your version was newer (Nov 24) and showing as beta. Could that be part of the issue?
Thanks for chiming in! That can’t be a coincidence that you also have a Qnine adapter. Your bootloader looks fine for sure, Maris was missing all of those options and yours look normal and he appears to have fixed that part of it.
I updated to the beta release just so I could get a screenshot of what it looks like when there’s an update available but I didn’t have the beta firmware to make this tutorial. Most others seem to have been successful as well.
We could definitely have you guys try the beta channel if you would be interested. According to the firmware release notes it looks like there have been dozens of fixes that aren’t in stable. Here’s some that caught my eye:
Don’t timeout a USB MSD device after USB_MSD_LUN_TIMEOUT if there are no other MSD devices or LUNs to try. This avoids unnecessary timeouts on very slow to initialise disk drives e.g. USB HDDs designed for backups.
Improve compatibility with external USB 3.0 disk enclosures by enumerating the downstream hubs before executing the USB port power off. N.B. Pi4 8GB automatically powers off the USB ports during chip-reset and does not need this change.
Fix failover to partition zero if the partition number is invalid. For USB MSD boot a start.elf update is also required.
Fix issue where boot would stop if partition type 0x83 was encountered before the first FAT partition.
XHCI protocol layer fixes for non-VLI controllers.
Those are just a few I saw in there that have been released since the September release firmware that is on stable. The first one I bolded in there looks particularly juicy as it specifically relates to timeouts for certain mass storage devices! The second one is also pretty interesting because I have an 8 GB Pi which apparently is immune but 4 GB and lower capacity Pis are not without the firmware update which at this time is in the beta channel.
Most people appear to be fine, but I think it would be worth you two trying the beta version. See my guide for instructions to change to the beta channel if you’re interested. If you aren’t comfortable going on the beta firmware then you can just wait until it’s released to stable which probably won’t be more than a couple of months.
Maris
I used the imaging tool to burn the OS on both the SSD and SD. The SSD took forever but now with the “real” image it boots as expected.
I’m suspicious of the Balena Etcher especially imaging from a zip.
Maris
I assume you mean an MSD adapter on the Pi 4. How to debug or fix.
Another question : what is the meaning of BOOT_ORDER=0xf41. It doesn’t match your notes wrt to setting the boot order.
You’re correct, I meant the mass storage device adapter. Check out my reply to Jon here but I think the only thing you can do other than try a different adapter is try the beta firmware. There have been some fixes in there that are related to booting and mass storage devices so that’s definitely worth a try! Normally I don’t recommend going on beta unless you have a specific problem that you need to fix. Both of you qualify in this case!
That’s a great question about the BOOT_ORDER. You can combine different codes together using the table in my article. Let’s break down 0xf41 as as an example:
0xf tells it to continuously restart the boot process if it fails. With this active you can power on the Pi without a SD card in it for example and if you put it in after it powers up it will succeed the next time it tries to reboot (it will retry forever). 0x1 is the SD card. So this example would equate to 0xf (restart on failure) + 0x4 (mass storage device) + 0x1 (sd card). This means boot from the mass storage device, if that fails try the SD card, and if that fails it will restart again from the beginning.
This is a nice feature and is very handy in certain situations where having a fallback is really valuable! You can actually add the other options in the table in there too if you wanted to add network booting in there you could change it to 0xf143 to have it try to network boot if mass storage and micro SD both fail. I’m adding this into the article because they recently changed the default to be 0xf41
I have several of both the StarTech 3.0 and 3.1 versions of the adapters and they have been reliable. I used one of them when writing this guide to connect with my SSD. I don’t recognize that Crucial model of CTX 500 though, is it a BX500? It definitely could be drive related, do you have any other types of drives you could test with around?
What problems have you been having? Maybe we can help. Which power adapter are you using for the Pi 4 8GB? You want to make sure yours is at least a 3.5A (you should be able to see this on the adapter if you look at the label). I’ve seen some kits coming with 3.0A supplies from last gen with the Pi 4 (and people reusing older ones, I’ve been guilty of this) and it’s fine until you connect something like a SSD that needs to draw power from it.
Another good thing to check is if you have a powered USB hub to try powering your drive off that instead of the Pi itself and see if things stabilize! Some SSDs can be quite power hungry, especially older ones.
(noob questions incoming)
Can I use your tutorial on my pi 3b+?
I’m planning on using your minecraft tutorials as well, would changing the bootloader mess anything up?
Thank you for all your work, so nice having all this info in one place.
I don’t think this one will work for the 3B+ because the Raspberry Pi 4 started coming with an new onboard EEPROM chip soldered into the board that the bootloader is stored on. This is how the bootloader settings can survive you putting in a different SD card for example. Older Raspberry Pis don’t have this chip and boot off the older way of using bootcode.bin and start.elf.
The good news is the 3B+ should support USB mass storage device booting right out of the box. Check out the bottom of the the Raspberry Pi USB mass storage device booting page for a little bit more info. Basically, you should be able to image your mass storage device just like you would a SD card and plug it in and it should be good to go!
That’s absolutely right! If you set the boot mode to 0x4 it will only attempt to boot from the USB mass storage device. If you wanted it to fall back to the SD card if it failed you could set the code 0x41 but I just have been leaving mine empty!
I updated the article to add this information to hopefully help others as well.
Great question. You have a couple of different paths you can take. If you want a similar setup to what you have now where everything is self contained I would check out the portable SSD section at my storage benchmark site here: Pi Benchmarks portable section
Of course the fastest option is going to be the more expensive one usually but even as soon as page 2 and 3 there are great performing drives that are very reasonably priced. These are basically the same as the setup you have now. The closest version to the Seagate Backup Plus is probably the Seagate One Touch SSD.
It’s typically not necessary to provide external power to the SSDs but honestly it is a nice feature to have on a Pi where you have limited power to work with and big power draws can cause issues. A popular alternative to consider is to actually get a powered USB hub. Basically you power the drive off the USB hub instead of the Raspberry Pi which takes all the power draw off the Pi. Keep in mind that you’re only likely to run into this problem with very powerful or very old power hungry drives and only if you are pushing your Pi to the absolute limits but still it is a consideration.
One note with the powered USB hubs is that you need to get one that doesn’t feed power back into the Pi. You have to be pretty careful here. I have this Sabrent one.
The reason I say to be careful is that with this type of equipment the manufacturers sometimes make changes to which chipsets they are using and things like that without spinning it into a new model. This has happened with storage adapters too where in the middle of a production run they start using a different chipset etc. I always check the Amazon reviews to make sure people receiving it *recently* are saying it’s working with the Pi. I double checked the Sabrent and saw people from early October saying it was working great on their Pi 4 to power an external drive so this looks like a safe bet, but if you’re reading this later you should verify it the same way!
The other option you can take is to use a USB adapter which allows you to use just about any SSD you want to. An example would be the StarTech 2.5″ SATA to USB Adapter. The adapters are very cheap. It’s especially cheap if you happen to have a spare/old drive anywhere!
If you want to go this route instead definitely check out the sections above where myself and other commenters have basically got together and determined which adapters suck and which ones are great. There are many different types of adapters/enclosures on there that have already basically been tested.
A great place to find SSDs to consider is the popular section of my storage benchmark site. This section is nice because it isn’t based on how fast it is but how many people are using it/benchmarking it so it isn’t just fast drives that cost hundreds of dollars. In fact, the most popular choice for a long time running now is the Kingston A400 which is around $25 when I wrote this comment and hovers between $20 or $30 for the past year or two.
Hi James,
I got my SSD worked well. I bought ELUTENG 2.5″ SATA to USB 3.0 Adapter and Sabrent 4-Port USB 3.0 Hub with Individual LED Lit Power Switches.
My SD card already had Dietpi. Then I followed this guide to clone my SD card to SSD. After that, I followed Editing Bootloader Configuration to make SSD boot.
That looks right to me and matches the Pi I just imaged to write this guide. I used the 64 bit beta version on my SD card which has the new support and the 32 bit image I put on the SSD also has it in there. This was my result:
Linux raspberrypi 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux
The easiest way to tell if you have the support is to try the command:
sudo -E rpi-eeprom-config --edit
If you are on a version that has the new bootloader utility it will open up the configuration in nano for you. If you are on an older version it will give you an error (I can’t recall what the exact error was off the top of my head, but I got it before I did a dist-upgrade on an older version of Raspbian).
It looks like the firmware that supports USB mass storage booting was made the default (critical) EEPROM image on 9/3/2020 according to the release notes. If your Raspbian is up to date you should be good to go, but you can double check that your firmware is updated with:
sudo rpi-eeprom-update
and to install the updates (if they are available):
Thanks for this guide James.
Do you have plans to update your guide for RPi4 Ubuntu now that the Raspberry Pi 4 Bootloader USB is out of beta? I hope this will make the setup for Ubuntu easier.
Hey Carto,
Thanks for the kind words! I definitely need to get the Ubuntu guide updated for sure and should be able to do so within the next week or so here.
I got a few other articles updated today and I’ll definitely bump that one up on the priority list since we now have a request for it!
UPDATE: I was able to finish this! Check it out here.
Thank you very much!
I will try it this weekend.
I am obviously missing something. Executing the ‘sudo -E rpi-eeprom-config –edit’ command loads a file ‘/tmp/tmpmf8ua9ol/boot.conf’ into nano.
The contents of the file :
BOOT_UART=0WAKE_ON-GPIO=1
POWER_OFF_ON_HALT=0
Adding the BOOT_LOADER params and saving (ctrl-X, Y with same file name) returns : ‘ERROR : rpi-eeprom-update -d -i -f /tmp/tmpjj_1frdu/pieeprom.upd timeout’.
The MSD is a Samsung 1TB 860EVO. The OS is 2020-09-20-raspios-buster-armhf. The adapter is an Orico 3 –Sata III.
The sudo rpi-eeprom-update -a output :
BCM2711 detectedBOOTLOADER: up-to-date
CURRENT: Thu 03 sep 2020 12:11:43 PM UTC (1599135103)
LATEST: Thu 03 sep 2020 12:11:43 PM UTC (1599135103)
FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 00013a1
LATEST: 00013a1
Orico prob ? Had a bunch of DEPENDENCY issues using Speiss method youtube #312
Advice ?
Hmmm, that doesn’t look quite right, it looks like an old configuration from before the USB boot support was added. Can you try restoring the bootloader to defaults using a:
sudo rpi-eeprom-update -a -dAlso when you said you were having a dependency issue is your apt package manager still functioning correctly? You may want to do a
sudo dpkg --configure -asudo apt update
sudo apt install --fix-broken
sudo apt full-upgrade
Let us know what you find!
Reflashed everything and did the updates and upgrades.
Exactly the same result. 🙁
Very curious. You are missing a lot of options. Check out the Raspberry Pi bootloader configuration page from the Raspberry Pi docs. Every configuration entry has a date from when it was added. Were the original 3 you posted the only ones in there still? That would date you all the way back to a 2019-07-15 bootloader configuration. Even the first one released in 2020 has additional options!
You should be able to update the firmware from Raspbian on a SD card. It won’t matter that you use the SSD again later since the firmware is stored on a chip. Do you have a spare SD card you could try from with a fresh Raspbian image to rule out the SSD/adapter? I haven’t encountered this before. I almost wonder if your bootloader is locked somehow or being overridden through some of the options that are in the link I posted in the first paragraph potentially?
Using the full blown official Raspberry Pi firmware/bootloader recovery image (see the “Restoring Bootloader to Defaults” section to see screenshots of this) may be in order potentially as well. What do you get from using the command:
vcgencmd bootloader_configIt appears my latest post didn’t make it.
Noting that I try seems to make any difference. vcgencmd bootloader_config returns the same three options as before as does the rpi-eeprom-update -a -d command.
I vaguely recall having timing issues with the 860EVO when I tried SSD boot a while ago (year?).
I ordered the same set-up that you describe above and I’ll attempt it again.
The weird thing is that the SSD should have nothing to do with it. That bootloader configuration on the Pi 4 is stored on a chip inside the Pi. The vcgencmd utility is essentially relaying the actual bootloader settings that the Pi is using directly from the SoC. I was hoping it was some kind of bug with the edit command and that it wasn’t your actual configuration but that definitely seems to confirm it.
Have you tried using the recovery image yet? Which SSD / SD card you use won’t make any difference. The bootloader is lower level than that. I know you said you reflashed, does that mean you used the official recovery image? And just to confirm, and I thought I said this somewhere in your older posts but now I’m not sure, this is a Pi 4? Because this won’t work for anything older than a 4 as they don’t have this bootloader.
Definitely a Pi 4 – 4GB
Prepping the recovery image as we speak.
The updated boot loader via vcgencmd bootloader_config
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
However :
This is the same error stream I got using Spiess’ youtube (#312) technique. On boot after diddling the SSD for 10 mins. :
Timed out waiting for device /dev/serial1
Dependency failed for Configure Bluetooth Modems connected by UART
Timed out waiting for device /dev/disk/by-portuuid/58ce116e-01
Dependency failed for /boot
…
and stop
Obviously rpi 4 don’t like Samsung 860EVO. I’ll try it with the 250G Kingston when it arrives.
That looks much better! At least your bootloader is functioning and correctly configured again. Everything I can find related to that error points to the partition UUID not matching your /etc/fstab file.
The Samsung 860 EVO is the 9th most popular SSD by number of submissions with over 322 benchmarks so far. I think the drive will be fine. The adapter is probably the culprit.
One other thing you should check is to try having the Raspberry Pi imaging tool create the SSD media for you. This would be the same tool you created the recovery image with. Have you tried that yet by chance? I only say this because I’ve seen some imaging tools mess up those PartUUIDs before so it may be worth giving a shot while you’re waiting!
I seem to have the same issues as Maris. I’m using a Qnine NMVe adapter with a Toshiba drive. My rpi-eeprom-update output and looks identical to his except my specified FW DIR is to the /stable directory rather than /critical. My rpi-eeprom-config file looks identical to his as well with the BOOT_ORDER=0xf41 rather than your example of just 0x4.
The thing that suck out to me looking at the difference between the update outputs was that your version was newer (Nov 24) and showing as beta. Could that be part of the issue?
Hey Jon,
Thanks for chiming in! That can’t be a coincidence that you also have a Qnine adapter. Your bootloader looks fine for sure, Maris was missing all of those options and yours look normal and he appears to have fixed that part of it.
I updated to the beta release just so I could get a screenshot of what it looks like when there’s an update available but I didn’t have the beta firmware to make this tutorial. Most others seem to have been successful as well.
We could definitely have you guys try the beta channel if you would be interested. According to the firmware release notes it looks like there have been dozens of fixes that aren’t in stable. Here’s some that caught my eye:
Those are just a few I saw in there that have been released since the September release firmware that is on stable. The first one I bolded in there looks particularly juicy as it specifically relates to timeouts for certain mass storage devices! The second one is also pretty interesting because I have an 8 GB Pi which apparently is immune but 4 GB and lower capacity Pis are not without the firmware update which at this time is in the beta channel.
Most people appear to be fine, but I think it would be worth you two trying the beta version. See my guide for instructions to change to the beta channel if you’re interested. If you aren’t comfortable going on the beta firmware then you can just wait until it’s released to stable which probably won’t be more than a couple of months.
I used the imaging tool to burn the OS on both the SSD and SD. The SSD took forever but now with the “real” image it boots as expected.
I’m suspicious of the Balena Etcher especially imaging from a zip.
I assume you mean an MSD adapter on the Pi 4. How to debug or fix.
Another question : what is the meaning of BOOT_ORDER=0xf41. It doesn’t match your notes wrt to setting the boot order.
Hey Maris,
You’re correct, I meant the mass storage device adapter. Check out my reply to Jon here but I think the only thing you can do other than try a different adapter is try the beta firmware. There have been some fixes in there that are related to booting and mass storage devices so that’s definitely worth a try! Normally I don’t recommend going on beta unless you have a specific problem that you need to fix. Both of you qualify in this case!
That’s a great question about the BOOT_ORDER. You can combine different codes together using the table in my article. Let’s break down 0xf41 as as an example:
0xf tells it to continuously restart the boot process if it fails. With this active you can power on the Pi without a SD card in it for example and if you put it in after it powers up it will succeed the next time it tries to reboot (it will retry forever). 0x1 is the SD card. So this example would equate to 0xf (restart on failure) + 0x4 (mass storage device) + 0x1 (sd card). This means boot from the mass storage device, if that fails try the SD card, and if that fails it will restart again from the beginning.
This is a nice feature and is very handy in certain situations where having a fallback is really valuable! You can actually add the other options in the table in there too if you wanted to add network booting in there you could change it to 0xf143 to have it try to network boot if mass storage and micro SD both fail. I’m adding this into the article because they recently changed the default to be 0xf41
I have 2 each of the StarTech USB3S2SATA3CB USB 3,0 STAT adapter and Crucial CTX 500 (250 MB) SSD and can report these have been very problematic for me with a Raspberry PI 4 8GB.
Hey Brad,
I have several of both the StarTech 3.0 and 3.1 versions of the adapters and they have been reliable. I used one of them when writing this guide to connect with my SSD. I don’t recognize that Crucial model of CTX 500 though, is it a BX500? It definitely could be drive related, do you have any other types of drives you could test with around?
What problems have you been having? Maybe we can help. Which power adapter are you using for the Pi 4 8GB? You want to make sure yours is at least a 3.5A (you should be able to see this on the adapter if you look at the label). I’ve seen some kits coming with 3.0A supplies from last gen with the Pi 4 (and people reusing older ones, I’ve been guilty of this) and it’s fine until you connect something like a SSD that needs to draw power from it.
Another good thing to check is if you have a powered USB hub to try powering your drive off that instead of the Pi itself and see if things stabilize! Some SSDs can be quite power hungry, especially older ones.
(noob questions incoming)
Can I use your tutorial on my pi 3b+?
I’m planning on using your minecraft tutorials as well, would changing the bootloader mess anything up?
Thank you for all your work, so nice having all this info in one place.
Hey Jonny,
I don’t think this one will work for the 3B+ because the Raspberry Pi 4 started coming with an new onboard EEPROM chip soldered into the board that the bootloader is stored on. This is how the bootloader settings can survive you putting in a different SD card for example. Older Raspberry Pis don’t have this chip and boot off the older way of using bootcode.bin and start.elf.
The good news is the 3B+ should support USB mass storage device booting right out of the box. Check out the bottom of the the Raspberry Pi USB mass storage device booting page for a little bit more info. Basically, you should be able to image your mass storage device just like you would a SD card and plug it in and it should be good to go!
doh, turns out my 3b+ was a 4 this whole time ha! I’ll no longer need a card in the microSD slot after I start booting off usb correct?
Thanks!
Hey Jonny,
That’s absolutely right! If you set the boot mode to 0x4 it will only attempt to boot from the USB mass storage device. If you wanted it to fall back to the SD card if it failed you could set the code 0x41 but I just have been leaving mine empty!
I updated the article to add this information to hopefully help others as well.
HA, I was able to top the benchmark list after an overclock.
works great!
That’s awesome Jonny, very impressive score, I’m glad you were able to get it working!
Hi James,
My pi 4 currently attached an external HDD Seagate Backup Plus 5TB. I’m looking for a recommended Enclosure Case SDD with power supply.
Thanks
Hey John,
Great question. You have a couple of different paths you can take. If you want a similar setup to what you have now where everything is self contained I would check out the portable SSD section at my storage benchmark site here: Pi Benchmarks portable section
Of course the fastest option is going to be the more expensive one usually but even as soon as page 2 and 3 there are great performing drives that are very reasonably priced. These are basically the same as the setup you have now. The closest version to the Seagate Backup Plus is probably the Seagate One Touch SSD.
It’s typically not necessary to provide external power to the SSDs but honestly it is a nice feature to have on a Pi where you have limited power to work with and big power draws can cause issues. A popular alternative to consider is to actually get a powered USB hub. Basically you power the drive off the USB hub instead of the Raspberry Pi which takes all the power draw off the Pi. Keep in mind that you’re only likely to run into this problem with very powerful or very old power hungry drives and only if you are pushing your Pi to the absolute limits but still it is a consideration.
One note with the powered USB hubs is that you need to get one that doesn’t feed power back into the Pi. You have to be pretty careful here. I have this Sabrent one.
The reason I say to be careful is that with this type of equipment the manufacturers sometimes make changes to which chipsets they are using and things like that without spinning it into a new model. This has happened with storage adapters too where in the middle of a production run they start using a different chipset etc. I always check the Amazon reviews to make sure people receiving it *recently* are saying it’s working with the Pi. I double checked the Sabrent and saw people from early October saying it was working great on their Pi 4 to power an external drive so this looks like a safe bet, but if you’re reading this later you should verify it the same way!
The other option you can take is to use a USB adapter which allows you to use just about any SSD you want to. An example would be the StarTech 2.5″ SATA to USB Adapter. The adapters are very cheap. It’s especially cheap if you happen to have a spare/old drive anywhere!
If you want to go this route instead definitely check out the sections above where myself and other commenters have basically got together and determined which adapters suck and which ones are great. There are many different types of adapters/enclosures on there that have already basically been tested.
A great place to find SSDs to consider is the popular section of my storage benchmark site. This section is nice because it isn’t based on how fast it is but how many people are using it/benchmarking it so it isn’t just fast drives that cost hundreds of dollars. In fact, the most popular choice for a long time running now is the Kingston A400 which is around $25 when I wrote this comment and hovers between $20 or $30 for the past year or two.
Hopefully that helps give some ideas to consider!
Hi James,
I got my SSD worked well. I bought ELUTENG 2.5″ SATA to USB 3.0 Adapter and Sabrent 4-Port USB 3.0 Hub with Individual LED Lit Power Switches.
My SD card already had Dietpi. Then I followed this guide to clone my SD card to SSD. After that, I followed Editing Bootloader Configuration to make SSD boot.
Thanks for your suggestion.
Excellent results John, I’m glad you got it working!
I am still getting a raspbian from Oct 22 build date when I try distro upgrade. Is this version compatible with USB Boot?
“`
uname -a
Linux raspberrypi4 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux
“`
Hey Adarsha,
That looks right to me and matches the Pi I just imaged to write this guide. I used the 64 bit beta version on my SD card which has the new support and the 32 bit image I put on the SSD also has it in there. This was my result:
Linux raspberrypi 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/LinuxThe easiest way to tell if you have the support is to try the command:
sudo -E rpi-eeprom-config --editIf you are on a version that has the new bootloader utility it will open up the configuration in nano for you. If you are on an older version it will give you an error (I can’t recall what the exact error was off the top of my head, but I got it before I did a dist-upgrade on an older version of Raspbian).
It looks like the firmware that supports USB mass storage booting was made the default (critical) EEPROM image on 9/3/2020 according to the release notes. If your Raspbian is up to date you should be good to go, but you can double check that your firmware is updated with:
sudo rpi-eeprom-updateand to install the updates (if they are available):
sudo rpi-eeprom-update -aand reboot.
This is my first jump into Raspberry PI. I am pretty excited to give this a go. Thank you for the post. I found you through Andreas Spiess.
Hey Jack,
Welcome to the Raspberry Pi world! Thanks for the kind words, I’ll have to thank Andreas!